[GRASS-dev] Re: [GRASS GIS] #1158: Removing vector map in Windows
fails with "Unable to delete vector map"
GRASS GIS
trac at osgeo.org
Fri May 13 21:50:14 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:35 mmetz]:
> The DBMI driver, at least the way it is called by Vect_delete(), does
not inherit any file pointers, it gets only the names of the driver,
database, and table.
A process doesn't inherit "file pointers", it inherits either descriptors
(Unix) or handles (Windows). On Unix, a child process inherits all of its
parent's descriptors. On Windows, the situation is more complex: the
!CreateProcess() function has a parameter, bInheritHandles, which
specifies whether inheritable handles are inherited by the child process
(inheritability is a property of a handle).
The Windows version of G_spawn_ex (which db_start_driver uses) sets the
bInheritHandles parameter to 1, as this is required in order to be able to
set std{in,out,err} for the child process (STARTF_USESTDHANDLES flag in
the STARTUPINFO structure). So the child process will inherit any
inheritable handles.
However, I don't know whether the handles which underlie the descriptors
returned by open() etc are inheritable. If they are, the DBMI driver
process will inherit the underlying handles from the parent, meaning that
the corresponding file cannot be deleted, renamed, etc while the driver is
running.
It should be possible to determine what is actually happening by making
the driver sleep() long enough so that it can be inspected with e.g.
Process Explorer.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1158#comment:36>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list