[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:38 glynn]:
 > Replying to [comment:37 mmetz]:
 >
 > > So does this mean that the DBMI driver is not properly closed?
 >
 > It certainly looks that way. Even if the client doesn't send
 DB_PROC_SHUTDOWN_DRIVER, the driver should get EOF on its stdin when the
 client terminates.
 >
 > Can you use e.g. Process Explorer and/or gdb to discover anything about
 the state of the driver process after the client terminates?

 Testing the same 6.4.2 installer on a different xp system, the DBMI driver
 is always closed. Weird. But removing a vector fails 9 out of 10 times,
 sometimes it succeeds. Since the driver is closed, I can not investigate
 it with e.g. Process Explorer. The driver remains open if I disable
 DB_START_PROCEDURE_CALL(DB_PROC_SHUTDOWN_DRIVER) in db_shutdown_driver(),
 so that seems to work.

 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.

 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.

 Markus M

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