[GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location]

[Paul Kelly]

On Sun, 7 Jan 2007, Glynn Clements wrote:

>
> Hamish wrote:
>
>> Instead of changing G_tempfile() to G_tempfile_in_mapset(), why not leave
>> G_tempfile() as-is and make a new G_tempfile_in_tmp() [or similar name] for the
>> few cases that need that?
>
> Because *most* usage of G_tempfile() doesn't need the file to reside
> in the mapset directory. It's the existing behaviour which is a
> special case.
>
> Essentially, there's no reason for the two (mapset directory and
> temporary directory) to be linked. Having them linked creates problems
> if you need to create a temporary file (e.g. for G_asprintf()) when
> you don't have a valid mapset, meaning that many libgis functions may
> require a valid mapset for no good reason.

Just to clarify, the special case here was running g.proj to create a new 
location when there aren't any locations existing. Any library functions 
called by g.proj that use G_tempfile will fail because there is no current 
mapset to put the tempfile into. But there are other issues that have come 
up from time to time, if you search for G_tempfile on Google. It is kind 
of a recurring nagging problem, more a usage problem than a problem with 
the function itself I think. The documentation for G_tempfile says it is 
supposed to be used for large temporary files like maps, where the system 
temp directory might not have enough space. But in practice it's come to 
be used whenever a temporary file is needed for anything, and it's not 
always suitable.

I feel if we don't make a wholesale change now it might lead to 
hard-to-detect little problems in years to come when everyone forgets 
about this and again assumes G_tempfile creates a "normal" temp file - It 
reminds me of the G_getl issue. I almost think it would have been better 
if G_getl had been re-written to support stripping Mac/DOS new line 
sequences as well as Unix ones instead of adding a new G_getl2 and 
changing case-by-case in modules. The newline problem causes loads of 
subtle problems on native Windows and it is often really hard to detect 
where, deep within a library that a call to G_getl should be replaced with 
G_getl2 to get round the problem.

>> As noted in an earlier post, there are cases (debugging, d.text, d.graph) where
>> it is useful to leave small tmp files around for the rest of the session.
>
> Right. However:
>
> 1. Such files don't need to persist between sessions.
>
> 2. If a module exits normally, we can assume that any temporary files
> which it hasn't removed are meant to persist for the remainder of the
> session.
>
> 3. If a module exits abnormally using G_fatal_error(), we may want to
> automatically remove any temporary files which it created (the only
> reason not to would be for debugging, and we can provide an
> environment variable for this purpose).
>
> For #3, it would help if we used a directory which was specific to
> GRASS (e.g. /tmp/grass-<user>-<session-pid> rather than /tmp) so that
> we don't have to worry about deleting something we shouldn't.

The issue here I think is (IIRC) that session directory is only created 
when you start a GRASS session from Init.sh, right? So if some external 
program is calling GRASS modules, e.g. QGIS or something (not 100% sure 
how it works) it would have been OK up to now with just a few environment 
variables set - if we make this change there will have to be an official 
GRASS "session" for G_tempfile to work. Unless I've missed something.
But yes I can't see any other way of easily deleting the temp files 
without accidentally deleting something else.