[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