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

[Glynn Clements]

Markus Neteler wrote:

> > Either terminate the session at the end of the day, or manually run
> > $GISBASE/etc/clean_temp occasionally. Unfortunately, this can't be
> > automated, as a few programs expect temporary files to survive for a
> > while after the program which created them has terminated.
> >
> > Mostly this is due to either:
> > 
> > a) a program creating a temporary file, then running some other
> > program with that temporary file as input.
> > 
> > b) d.text, which saves its input in a temporary file; this file needs
> > to remain until the monitor is erased, as it will be used if the
> > monitor needs to be redrawn (either via d.resize/d.redraw or, for
> > XDRIVER, if the monitor is resized via the window manager).
> > 
> > Apart from that, I suspect that a lot of programs need to take more
> > care to remove temporary files once they are no longer needed.
> 
> Yes.
> 
> Another suggestion may be a GRASS daemon which get's informed about
> temp files and can delete them later (rather than the  simplistic 
> clean_temp approach). We should probably centralize such management
> functionality.

First, I think that widespread implementation of Eric's suggestion
(unlinking the file immediately upon creation) will mostly solve the
problem.

While temporary files would still accumulate, this would be limited to
the relatively few programs which actually need the temporary file to
be accessible by other programs. AFAICT, most programs which create
temporary files would work with an "anonymous" file, although a few
might need minor changes (i.e. fseek()ing to the beginning of the file
rather than close()ing and re-open()ing it).

Also, it may be worthwhile running clean_temp on startup. This would
catch the case where a previous session (using the same mapset)
terminated abnormally.

Regarding a cron job: it would probably be safe to delete temporary
files which were more than a day old. It seems unlikely that files
which are that old would still be in use.

As for d.text; the issue indicates a fundamental problem with the
concepts which underlie d.save etc. These issues will need to be
addressed fully if the ability to switch location/mapset is to be
fully realised.

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