[GRASS-dev] Re: [GRASS GIS] #1158: Removing vector map in Windows fails with "Unable to delete vector map"

[GRASS GIS]

#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 mmetz):

 Replying to [comment:36 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.

 I had the opportunity to test 6.4.2 on xp using v.in.ascii and noticed
 that the DBMI driver, in this case dbf, remains open and is not closed.
 Even manual deletion of the affected files does not work because they are
 still used by the DBMI driver. The files could be deleted only after
 manually killing the DBMI driver. BTW, the DBMI driver kept running after
 closing GRASS and any msys consoles.

 So does this mean that the DBMI driver is not properly closed?

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1158#comment:37>
GRASS GIS <http://grass.osgeo.org>