[GRASS-dev] Re: [GRASS GIS] #1276: r.null after v.to.rast in winGRASS does not work properly (was: r.null in winGRASS does not work properly)

[GRASS GIS]

#1276: r.null after v.to.rast 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, v.to.rast, wingrass  |    Platform:  MSWindows 7              
      Cpu:  Unspecified                  |  
-----------------------------------------+----------------------------------
Changes (by hamish):

  * keywords:  r.null, wingrass => r.null, v.to.rast, wingrass


Comment:

 Replying to [comment:17 glynn]:
 > Er, what?

 just that the warning messages need to be better targeted so that they
 only print in cases when they are meaningful. (and don't try to remove() a
 file which doesn't exist, etc)

 > 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.

 The failing r.null is the symptom, I would guess that `g.remove rast` for
 that map would also fail (untested) as the zombie v.to.rast process would
 still have the cell file open.


 > 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.

 is r50497 "SF_CLOSE_DESCRIPTOR should actually close the descriptor"
 related? should it be backported?


 Hamish

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