[GRASS-dev] Re: [GRASS GIS] #1158: Removing vector map in Windows
fails with "Unable to delete vector map"
GRASS GIS
trac at osgeo.org
Thu May 12 04:55:48 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 mmetz):
Replying to [comment:34 glynn]:
> Replying to [comment:30 mmetz]:
>
> > > I know that they '''shouldn't''' be open, but are they? See
comment:3.
> > >
> > OK. I suggest Vect!__open_old() and Vect_open_new() should initialize
all file pointers to NULL and Vect_close() should close anything that is
not NULL.
>
> That won't help if the problem is being caused by the DBMI driver
inheriting the descriptor and not terminating before the file is deleted.
I don't know if this is what's causing the problem, but there appear to be
cases where it can happen.
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.
The only two file pointers in the map_info structure are those for the
hist and the coor file, and so far only these two files gave problems, but
not dbln, cidx, sidx, topo. Coincidence? Vect_close() does indeed close
the file pointers for hist and coor, I tested.
>
> > Unfortunately, G_zero() does not set all contents of the Map_info
structure to 0 or NULL
>
> How come?
Can't reproduce any more, please ignore.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1158#comment:35>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list