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

[Glynn Clements]

Markus Neteler wrote:

> > > > 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.
> 
> Yes, it looks nice. Eric, do you want to submit that?

The addition of G_tempfile2() isn't the issue; even without any new
library functions, you can just add calls to unlink() where necessary. 
The issue is changing the various modules to use it. And most of the
work there is in determining whether the code can use an "anonymous"
file, or if it requires that the file can be re-opened, because
either:

a) the same program later closes and reopens the file, or
b) the program calls some other program with the filename as an argument.

> > 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.
> 
> Mhh. But what if the user doesn't leave GRASS for a week or
> just continues two days later due to Sunday?

AFAICT, this only concerns d.text[.freetype]. The other cases where
the file can't be immediately unlink()ed are where one program creates
a file for another to read. It seems highly unlikely that the reader
won't open the file within a day of the writer closing it.

One obvious fix for d.text[.freetype] is to allow the text to be read
from a command-line argument, so that the command which is passed to
D_add_to_list() needn't reference a temporary file.

The only issue with that is if the length of the text exceeds the
available environment space (4Kb is typical); that seems rather
unlikely.

Of course, if D_add_to_list(), d.save, monitor redraw etc are
scrapped, the whole issue becomes moot. However, that isn't something
for 5.0.x.

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