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

[Hamish]

Paul wrote:
> I've had the attached changes (to G_tempfile(), g.tempfile and a couple of 
> other places) sitting around for a while, but Michael's comment about changes
> to g.proj being forthcoming reminded me to hurry up and put them forward for 
> discussion. The changes amount to:
> * Re-naming the current G_tempfile() to G_tempfile_in_mapset().
> * Change the calls to G_tempfile() in lib/gis/opencell.c to use the new
>   function G_tempfile_in_mapset()
> * Write a new G_tempfile() that puts a tempfile in the directory pointed to 
>   by the TEMP environment variable if it exists (this will be somewhere
>   writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or 
>   root of current drive on Windows).
> * Add a new command-line flag to g.tempfile to allow it to create a tempfile 
>   in the current mapset if necessary.
> * Change r.in.aster (as an example) to use g.tempfile in this way. There 
>   would be more examples I'm sure we could find that want to create a large
>   tempfile somewhere there's more than likely to be enough space - the 
>   original purpose of G_tempfile, according to comments in the source. 
>   Although perhaps that's not all that relevant. Perhaps in the past /tmp 
>   might have been likely to be very small?

depends on how the user partitioned their drive. It's common to have /tmp in a
small partition to prevent out of disk space DoS attacks.


</gone>

Hi, & a happy 2007,

I have a few problems/questions with this.

Such a big change to the way things are done requires an extrodinary reason.
What's the need? [sorry not well set up to pour through the archives here]
Is is just for creating new locations? (a single case when $MAPSET doesn't
exist yet)

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? Patches which do not address fundamental flaws in the
system should follow the path of least damage. (patches which *do* address
funamental flaws are of course another matter.)

> The reason I haven't applied the changes yet is that I'm slightly worried 
> about what the effect might be of the sudden change. In particular, that
> tempfiles created by the current G_tempfile (i.e. in the current mapset) get 
> cleaned up at the end of the session and after the change they won't. Should
> we just change it and fix things on a case-by-case basis? (Either change 
> them to create the tempfile in the mapset, or force them to delete it?) A 
> bit of a dilemma.

if in /tmp/ shouldn't they live in /tmp/grass-$USER-$$/, which gets removed
when grass exits? [nb the /tmp/grass-$USER rmdir currently buggy if creating
new locn or if you "Cancel" on the startup screen]

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.

While we are on the subject, still missing: G_tempdir() and "g.tempfile -d"


Hamish

(note heavy lack of sympathy for any change that messes up the grass code to
accomodate broken/quirky {Windows|3rd party} compatibility software.)


ps - don't mess with "g.region -g"
pps- ps.map verbose command IS used in the wild, so don't break scripts by
removing it altogether. Note it is multi-leveled, so it should keep at least 3
levels of verbosity triggered by --q,<>,--v, i.e. standard messages should use
G_message(), but very verbose messages should hide G_message() in if(verbose >=
G_max_verbose()) or whatever. I am in favour of separating mapping commands
from program control, and letting the parser deal with the latter.

<gone>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com