[GRASS-dev] Re: [GRASS GIS] #1276: r.null in winGRASS does not work
properly
GRASS GIS
trac at osgeo.org
Fri Jan 27 07:27:21 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 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>
More information about the grass-dev
mailing list