[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