#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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev