[GRASS-dev] Re: [GRASS GIS] #1276: r.null in winGRASS does not work
properly
GRASS GIS
trac at osgeo.org
Tue Jan 24 01:39:24 EST 2012
#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 hamish):
Replying to [comment:6 glynn]:
> 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.
From the timestamps (and r.info showing the correct range) I can confirm
that cell_misc/$MAP/null and cell_misc/$MAP/range are updated when running
r.null on Windows XP, but cell/$MAP's timestamp is not updated.
> 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.
...
> 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.
done in r50404 in devbr6.
bug: close(fd) is called twice, (??)
https://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/lib/gis/closecell.c#L287
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1276#comment:10>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list