I've had the attached changes (to G_tempfile(), g.tempfile and a couple of other places) sitting around for a while, but Michael's comment about changes to g.proj being forthcoming reminded me to hurry up and put them forward for discussion. The changes amount to:
* Re-naming the current G_tempfile() to G_tempfile_in_mapset().
* Change the calls to G_tempfile() in lib/gis/opencell.c to use the new function G_tempfile_in_mapset()
* Write a new G_tempfile() that puts a tempfile in the directory pointed to by the TEMP environment variable if it exists (this will be somewhere writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or root of current drive on Windows).
* Add a new command-line flag to g.tempfile to allow it to create a tempfile in the current mapset if necessary.
* Change r.in.aster (as an example) to use g.tempfile in this way. There would be more examples I'm sure we could find that want to create a large tempfile somewhere there's more than likely to be enough space - the original purpose of G_tempfile, according to comments in the source. Although perhaps that's not all that relevant. Perhaps in the past /tmp might have been likely to be very small?
The reason I haven't applied the changes yet is that I'm slightly worried about what the effect might be of the sudden change. In particular, that tempfiles created by the current G_tempfile (i.e. in the current mapset) get cleaned up at the end of the session and after the change they won't. Should we just change it and fix things on a case-by-case basis? (Either change them to create the tempfile in the mapset, or force them to delete it?) A bit of a dilemma.
Paul
(attachments)
diff.txt (11.1 KB)
At least as far as the GUI goes, it tries to do its own cleanup of the
tempfiles it creates. The development wxPython one does the same. AFAICT,
these were never cleaned up automatically anyway. I wish they were, but it
prompted me to include cleanup code that should be helpful in the current
circumstance.
Michael
On 1/6/07 7:57 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
I've had the attached changes (to G_tempfile(), g.tempfile and a couple of
other places) sitting around for a while, but Michael's comment about
changes to g.proj being forthcoming reminded me to hurry up and put them
forward for discussion. The changes amount to:
* Re-naming the current G_tempfile() to G_tempfile_in_mapset().
* Change the calls to G_tempfile() in lib/gis/opencell.c to use the new
function G_tempfile_in_mapset()
* Write a new G_tempfile() that puts a tempfile in the directory pointed
to by the TEMP environment variable if it exists (this will be somewhere
writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or
root of current drive on Windows).
* Add a new command-line flag to g.tempfile to allow it to create a
tempfile in the current mapset if necessary.
* Change r.in.aster (as an example) to use g.tempfile in this way. There
would be more examples I'm sure we could find that want to create a large
tempfile somewhere there's more than likely to be enough space - the
original purpose of G_tempfile, according to comments in the source.
Although perhaps that's not all that relevant. Perhaps in the past /tmp
might have been likely to be very small?
The reason I haven't applied the changes yet is that I'm slightly worried
about what the effect might be of the sudden change. In particular, that
tempfiles created by the current G_tempfile (i.e. in the current mapset)
get cleaned up at the end of the session and after the change they won't.
Should we just change it and fix things on a case-by-case basis? (Either
change them to create the tempfile in the mapset, or force them to delete
it?) A bit of a dilemma.
Paul
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Paul Kelly wrote:
* Write a new G_tempfile() that puts a tempfile in the directory pointed
to by the TEMP environment variable if it exists (this will be somewhere
writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or
root of current drive on Windows).
Unix uses $TMPDIR rather than $TEMP. I'd suggest that G_tempfile()
should use $TMPDIR in preference to /tmp, to eliminate potential
security issues related to the use of world-writable directories,
although this isn't necessary if a private subdirectory is used.
The reason I haven't applied the changes yet is that I'm slightly worried
about what the effect might be of the sudden change. In particular, that
tempfiles created by the current G_tempfile (i.e. in the current mapset)
get cleaned up at the end of the session and after the change they won't.
Should we just change it and fix things on a case-by-case basis? (Either
change them to create the tempfile in the mapset, or force them to delete
it?) A bit of a dilemma.
I would suggest using a private subdirectory of /tmp ($TEMP, $TMPDIR),
linked to a particular session (i.e. use $GIS_LOCK in the directory
name) so that we can clean it up safely.
Was there a reason for not using the /tmp/grass-<user>-$GIS_LOCK
directory (where the monitor sockets are stored)?
I do feel that we should figure out a solution which allows for
cleaning up (i.e. not using a directory which is shared with temporary
files created by programs other than GRASS) before changing anything.
--
Glynn Clements <glynn@gclements.plus.com>