[GRASS-dev] [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display

[GRASS GIS]

#560: WinGRASS not deleting temp ppm files from map display
----------------------------------------+-----------------------------------
 Reporter:  isaacullah                  |       Owner:  grass-dev@…              
     Type:  defect                      |      Status:  new                      
 Priority:  critical                    |   Milestone:  6.4.3                    
Component:  Display                     |     Version:  6.4.0 RCs                
 Keywords:  v.digit ppm temp, wingrass  |    Platform:  MSWindows XP             
      Cpu:  x86-32                      |  
----------------------------------------+-----------------------------------

Comment(by hamish):

 Ok, if $GISRC is custom you'd get tmp files in weird places. (render.py
 could test if the getenv string started with "/tmp/grassX-" before using
 that, otherwise use $TMPDIR?)

 Right or wrong, many modules leave left-over files in $MAPSET/.tmp/,
 either due to design or a crash, and wherever they are it's rather nice
 that they get cleaned up automatically by the clean_temp program (if users
 wish to bypass normal startup and not run clean_temp, then it's their
 responsibility to look after that manually). What I am looking for with
 the `dirname $GISRC` idea is some way to replicate that auto-cleanup for
 GUI .ppm files that are forgotten, undeletable-at-runtime on Windows, and
 the residual results of the GUI crashing before cleaning itself up.

 it's probably mainly of concern for large raster maps, where it's not a
 concern at all since in $MAPSET/.tmp/, but fwiw it's good to consider that
 /tmp/ is often on a much smaller filesystem than $GISDBASE. For example,
 v.in.ascii might make a multi GB tempfile during its scanning step.

 > Most uses of G_tempfile() are wrong

 what's the potential downside of that? why "wrong" instead of "different"?
 i.e. is it theoretically wrong or practically wrong?


 thanks,
 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/560#comment:22>
GRASS GIS <http://grass.osgeo.org>