[GRASS-dev] Re: [GRASS GIS] #520: r.terraflow/iostream does not
respect STREAM_DIR option
GRASS GIS
trac at osgeo.org
Tue Jul 7 10:01:36 EDT 2009
#520: r.terraflow/iostream does not respect STREAM_DIR option
---------------------+------------------------------------------------------
Reporter: mmetz | Owner: grass-dev at lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.terraflow, tmp
Platform: All | Cpu: All
---------------------+------------------------------------------------------
Comment (by hamish):
Replying to [comment:18 mmetz]:
> Not respecting a user-specified STREAM_DIR option was apparently
> a bug of G_parser(), not r.terraflow.
actually it was hardcoded, MN just fixed it: r38256, L584
the G_parser() memory bug possibly made the earlier debugging effort very
confusing because if the option was left blank the last given value was
used anyway(?)
> The default answer of /var/tmp or another system TEMP folder
> is IMHO not a good idea because of lack of space. Why not
> leaving it blank, if no answer is given, use the GRASS temp
> directory? That directory should always exist and I guess there
> is most of the time enough space.
this has been discussed before, check the archives. ISTR that the
Terraflow team (Andrew? Laura?) explained why they used that a long time
ago (I now forget exact reason), but in the more recent discussion using
/home/mapset/.tmp/ had some popular support. Note that these temp files
may be >2gig (use the memory= option to lower those needs), and they may
be potentially useful(?) for inspection/archive/debugging/reuse later, so
keeping them completely hidden may not be desired.
The current %TEMP% solution on ms-windows seems reasonable to me.
I do not feel too strongly about the choice of /tmp/, /var/tmp/, or
G_tempfile() for GRASS 7 on unix.
Just that if we use a G_tempfile() solution we would be best to have a new
G_tempdir() function instead of using possibly non-portable filesystem
tricks for that.
you can read some of my earlier bitching and moaning about that here:
http://thread.gmane.org/gmane.comp.gis.grass.devel/17750/focus=17762
regards,
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/520#comment:19>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list