[GRASS-dev] Re: [GRASS GIS] #1276: r.null in winGRASS does not work properly

[GRASS GIS]

#1276: r.null in winGRASS does not work properly
------------------------------+---------------------------------------------
 Reporter:  helena            |       Owner:  grass-dev@…              
     Type:  defect            |      Status:  new                      
 Priority:  critical          |   Milestone:  6.4.2                    
Component:  Raster            |     Version:  6.4.1 RCs                
 Keywords:  r.null, wingrass  |    Platform:  MSWindows 7              
      Cpu:  Unspecified       |  
------------------------------+---------------------------------------------

Comment(by glynn):

 Replying to [comment:14 hamish]:

 > rather than just adding a only-remove if it exists (using e.g. stat())
 which may hide an error, it will be better to use the branch conditionals.
 (more work, but worth it)

 Er, what?

 > ok, the annoyance of seeing those warnings all the time will be
 motivating for the task..

 The warnings shouldn't have been added in the first place. The remove() is
 only necessary on Windows; on Unix, rename() will replace the destination
 if it exists. On either platform, if the remove() fails, the subsequent
 rename() should also fail, so there's no particular need to check the
 result of remove() (other than for debugging this particular issue).

 > trying 'v.to.rast --overwrite' to replace the cell/ file still gives me
 problems:

 This ticket relates to r.null. As previously mentioned, vector modules
 have their own issues, which belong on a separate ticket.

 Replying to [comment:16 hamish]:

 > ok, with perror(path) in place I see .../cell/mapname: Permission
 denied. Checking in the Windows Task Manager I see that a leftover dbf.exe
 and cmd.exe are still running after v.to.rast has finished. If I kill the
 dbf.exe the cmd.exe goes away too, then r.null seems to work.

 So this is specifically about running r.null on a map created by a vector
 module? Does r.null work correctly on maps not created by vector modules?
 If so, the title should be updated to reflect that.

 In that case, the problem is one of the DBMI driver failing to terminate
 along with its parent. I note that db__recv_procnum() only returns DB_EOF
 if db__recv() returns 0 (indicating EOF). If it returns an error, it will
 return DB_OK. Try r50496.

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