[GRASS-dev] [GRASS GIS] #3635: Suspicious use and cleanup of the mapset tempoary directory
GRASS GIS
trac at osgeo.org
Fri Aug 31 20:14:11 PDT 2018
#3635: Suspicious use and cleanup of the mapset tempoary directory
-------------------------------------------------+-------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.6.0
Component: Startup | Version: svn-trunk
Keywords: init grass.py clean_temp .tmp temp | CPU: Unspecified
g.mapset wxGUI rendering |
Platform: All |
-------------------------------------------------+-------------------------
Similarly to wrong lockfile being removed in #3631, `grass.py` seems to
clean and remove temporary directory associated with a mapset (during one
startup procedure and during shutdown). However, when mapset is switched
during the session, the clean up still happens in the initial mapset.
The clean up seems to be introduced in r54467 (before 7.0). Note that
''location'' here means ''full path to the mapset'' and the variable is
not changed after initialization to the "start time" mapset. At the same
time `$GISBASE/etc/clean_temp` is being called. Why `clean_temp` is not
sufficient?
A reason I can see is that there seems to be a problem with GUI which
continues to use the old mapset even after the switch for rendering (PPM
and vector legend). The comment in `grass.py` indeed says "remove GUI
session files from .tmp". Shouldn't it use the system temporary directory
or always get the current mapset?
Consequently, after turning of GRASS GIS, the initial mapset's `.tmp` is
removed completely while the current mapset's `.tmp` is cleaned in a
sophisticated way using `clean_temp`. Then I would say the GUI needs to
make sure to use the current mapset or not use mapset's temporary
directory at all and that `grass.py` should only do cleaning using
`clean_temp`. Does this make sense or am I missing something?
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3635>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list