[GRASS-dev] Re: [GRASS GIS] #1158: Removing vector map in Windows
fails with "Unable to delete vector map"
GRASS GIS
trac at osgeo.org
Sun Aug 28 17:12:18 EDT 2011
#1158: Removing vector map in Windows fails with "Unable to delete vector map"
--------------------------------------------------------------------------+-
Reporter: lponti | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 6.4.2
Component: Vector | Version: 6.4.0
Keywords: wingrass, g.mremove, wildcards, v.in.ogr, v.select, g.remove | Platform: MSWindows 7
Cpu: Unspecified |
--------------------------------------------------------------------------+-
Comment(by glynn):
Replying to [comment:39 mmetz]:
> The driver remains open if I disable
DB_START_PROCEDURE_CALL(DB_PROC_SHUTDOWN_DRIVER) in db_shutdown_driver()
That's not good; the EOF when the client terminates should be enough. But
that's another problem.
> Removing a vector always succeeds if I insert Sleep() (Uppercase Sleep)
for some few hundred milliseconds in db_shutdown_driver(), after _cwait()
is called. I am not sure if this is a solution or just a workaround.
Can you try modifying lib/db/dbmi_client/shutdown.c to use G_wait()
instead of _cwait()? _cwait() is only defined as working with process IDs
returned from the _spawn functions, which are no longer used.
> BTW, driver->pid refers to the PID of the instance of cmd.exe associated
with the driver, e.g. dbf.exe, not the PID of dbf.exe itself, but that
does not seem to cause problems.
For testing, it might help to apply attachment:spawn.c-no-shell.patch .
That can't be applied generally, as it will prevent G_spawn[_ex] from
working with scripts, but it may make it easier to deal with this specific
issue. For the general case, we might want to disable the use of a shell
if the program name ends in ".exe", or we might need to add a SF_SHELL (or
SF_NO_SHELL) flag.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1158#comment:40>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list