[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:5 hamish]:
 > I strongly suspect the trouble is on this line of r.null/mask.c:
 {{{
   if (change_null && G_is_null_value(rast, data_type))
         G_set_raster_value_d(rast, new_null, data_type);
 }}}
 >
 > new_null is always sent as DCELL, but data_type changes.

 That isn't a problem; as the _d suffix indicates, the source value is
 always DCELL; data_type indicates the type of the destination. The whole
 point of G_{get,set}_raster_value_{c,f,d} is to convert values between a
 type which is fixed at compile time and a type which is only known at run
 time.

 My suspicion is that the null bitmap is being updated but the cell/fcell
 file isn't. Null values always have a zero stored in the cell/fcell file,
 so clearing the null bitmap without updating the cell/fcell file will
 replace nulls with zeros. If this is the case, it should be
 straightforward to confirm it by checking the timestamps on the files.

 That this only happens on Windows suggests that it may be related to
 Windows' different filesystem semantics (e.g. not being able to
 rename/remove open files). Also, r.null is unusual in that it opens the
 same map for both reading and writing. It does close the input map before
 the output map.

 If it only happens on Windows 7 and Vista (but not XP): is GISDBASE in a
 directory which is !VirtualStore'd (e.g. Program Files)? That could
 potentially cause these exact symptoms. The null bitmap is modified in-
 place, but the cell/fcell files are generated in the temporary directory
 then rename()d over the original file when closed. This might result in
 the new cell/fcell file being silently redirected to the !VirtualStore
 directory (%LOCALAPPDATA%\!VirtualStore); although I don't know why it
 wouldn't then be read instead of the original file.

 Also, I notice that close_new() (in lib/gis/closecell.c) doesn't examine
 the return codes from either close() or remove(); it may be worth checking
 those.

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