[GRASS5] Re: [GRASSLIST:4564] Re: .tmp files

[Markus Neteler]

On Wed, Sep 25, 2002 at 01:32:38PM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > The issue is changing the various modules to use it.
> > 
> > E.g. one problem is v.to.rast. It doesn't use G_tempfile() at all but
> > a private solution instead
> 
> What? Where? I couldn't find anything (other than popen(), which
> doesn't create any files).

ok, I have no idea how v.to.rast works. But it generates two
files in 
location/mapset/.tmp/`uname -n`/

> > (and does not delete anything when this process is killed - signal
> > handler required here?).

If you kill v.to.rast with CTRL-C, these temp files remain until
you leave GRASS. The local README says that G_tempfile() is not used
(which grep confirms).
 
> Signal handlers are an option if the file can't be unlink()ed. But
> that still doesn't handle every case. It won't handle power failure,
> hardware reset, instant reboot due to a kernel panic, or SIGKILL. 
> 
> Also, it's risky trying to do too much when handling exceptions such
> as SIGSEGV, SIGBUS etc, as they tend to indicate a program
> malfunction, which may have corrupted memory.
> 
> Another issue: it may be better to create temporary files in a
> standard directory (/tmp, /var/tmp, or $TMPDIR), as many systems will
> clean those automatically (e.g. upon reboot).

A good idea. It also solves for many users the problem of finding the .tmp/
file (who expects it in the mapset/.tmp/ ...).

Maybe we add an optional
GRASS_TMPDIR=/tmp/grass-$USER/tmpfiles/
and set it per default to that directory.

The directory /tmp/grass-$USER is already in use for the monitors.
The $ETC/clean_temp may delete $GRASS_TMPDIR then.

Markus