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

[Glynn Clements]

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).

Well, src/mapdev/v.to.rast/README says:

    (1) It does not use a temporary file. Results go directly to the raster map.
	It does this by making one or more passes thru the vector map,
	rasterizing only a fixed number of rows (in memory, default 512),
	writing these rows to the raster map, and then repeating for the
	next set of rows, etc;

However, G__open_raster_new() creates temporary files for the data and
null rasters. However, G_close_cell(), G_unopen_cell() etc should move
these into the correct locations.

This indicates the location of the temporary directories; they have to
be on the same filesystem as the mapset directory.

In light of what's in the README, it may be that it's opening the
output more times than it's closing it.

> > 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.

This could work for "normal" temporary files, but not for those used
internally by G__open_raster_new(); maybe other functions do something
similar.

We would have to split G_tempfile() into one function which creates
"detached" temporary files which can go anywhere, and a different
function which is guaranteed to create them on the same filesystem as
the mapset.

-- 
Glynn Clements <glynn.clements at virgin.net>