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

[Bernhard Reiter]

On Tue, Sep 24, 2002 at 04:02:37PM +0200, Markus Neteler wrote:
> On Tue, Sep 24, 2002 at 03:53:30PM +0200, Roger Bivand wrote:
> > On Tue, 24 Sep 2002, Markus Neteler wrote:

> > > One problem is that some GRASS modules open temp files with
> > > G_tempfile() but do not remove them on exit.
> > > We were talking about that also in May:
> > > 
> > > http://grass.itc.it/pipermail/grass5/2002-May/002978.html
> > > 
> > > > 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:

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

I don't think a daemon is a good idea.
I'm not that familiar with GRASS' way of doing locking, but I 
suggest to add some meta information to the file, just as a lock
and this should contain the expected time to live.

At the end of a GRASS session all temp files should be deleted
On the start of a GRASS session or at a cron job, files with
an expired time to life can be removed.

We could also have several tmp directories.
Some let files live for 10 minutes, other for a day.
This would be another easy way to save the time to life information.

> > What about a cron job - FAQ entry to suggest to people to have cron clear 
> > up their temp files. Do we know which ones need to be protected from 
> > removal - this is also info a daemon might need?
> 
> exactly. We need a tool to distinguish between temp-in-use and oldish
> temp files. That's why they may be registered at the daemon. The daemon
> can watch processes running and check if they terminated/got killed.

I guess that a deamon will bring additional architectural problems:
	- it needs memory
	- we need a daemon to check if the daemon is running (just kidding.)
	- to make platform compatible daemon and IPC to them is *difficult*
	- we do not save extra information
	- it handles stuff that the operating system should handle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20020924/51978344/attachment.bin