[GRASS-dev] [GRASS GIS] #1158: g.mremove fails when used with wildcard in WinGRASS-6.4.0-1

GDAL · March 27, 2011, 3:28pm

#1158: g.mremove fails when used with wildcard on Windows + needs to be used twice
--------------------------------------------+-------------------------------
Reporter: lponti | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: Vector | Version: 6.4.0
Keywords: wingrass, g.mremove, wildcards | Platform: MSWindows 7
Cpu: x86-32 |
--------------------------------------------+-------------------------------

Comment(by hellik):

see also from qgis:

"GRASS toolbox: error removing vectors from a mapset under Windows"
https://trac.osgeo.org/qgis/ticket/3646

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

GDAL · March 27, 2011, 3:51pm

#1158: g.mremove fails when used with wildcard on Windows + needs to be used twice
--------------------------------------------+-------------------------------
Reporter: lponti | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.1
Component: Vector | Version: 6.4.0
Keywords: wingrass, g.mremove, wildcards | Platform: MSWindows 7
Cpu: x86-32 |
--------------------------------------------+-------------------------------
Changes (by hellik):

* priority: major => critical

Comment:

tested with WinGRASS-6.4.SVN-r45757-1-Setup.exe

{{{
g.remove vect=myfire@user1
Removing vector <myfire@user1>
Kann Datei 'C:\gisdata\grassdata/nc_spm_08/user1/vector/myfire/hist' nicht
löschen.
couldn't be removed
<myfire> nothing removed
(Sun Mar 27 17:47:12 2011) Command finished (0 sec)
(Sun Mar 27 17:47:13 2011)
g.remove vect=myfire@user1
Removing vector <myfire@user1>
}}}

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

GDAL · March 27, 2011, 3:52pm

#1158: g.mremove fails when used with wildcard on Windows + needs to be used twice
--------------------------------------------+-------------------------------
Reporter: lponti | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.1
Component: Vector | Version: 6.4.0
Keywords: wingrass, g.mremove, wildcards | Platform: MSWindows 7
Cpu: x86-32 |
--------------------------------------------+-------------------------------

Comment(by hellik):

Replying to [comment:15 hellik]:
> any hints for setting breakpoints? in the wiki
(http://grass.osgeo.org/wiki/GRASS_Debugging#Using_GDB) there aren't any
hints.
>

any hints?

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

GDAL · April 19, 2011, 7:49am

#1158: Removing vector map in Windows fails with "Unable to delete vector map"
--------------------------------------------------------------------------+-
Reporter: lponti | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.1
Component: Vector | Version: 6.4.0
Keywords: wingrass, g.mremove, wildcards, v.in.ogr, v.select, g.remove | Platform: MSWindows 7
Cpu: Unspecified |
--------------------------------------------------------------------------+-
Changes (by marisn):

  * keywords: wingrass, g.mremove, wildcards => wingrass, g.mremove,
               wildcards, v.in.ogr, v.select, g.remove
  * cpu: x86-32 => Unspecified

Comment:

I changed bug summary to better reflect it's scope.

It affects also v.in.ogr removal of temporary files (coor and not hist
file). Bug #1303

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

GDAL · April 19, 2011, 8:10am

#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 |
--------------------------------------------------------------------------+-
Changes (by martinl):

* priority: critical => blocker
* milestone: 6.4.1 => 6.4.2

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

GDAL · April 19, 2011, 9:26am

#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:23 marisn]:
> I changed bug summary to better reflect it's scope.
>
> It affects also v.in.ogr removal of temporary files (coor and not hist
file). Bug #1303

Hopefully fixed for devbr in r46041.

Vect_delete() uses unlink(), whereas raster and all other files are
removed by remove(): the file will remain in existence until the last file
descriptor referring to it is closed (at least on Linux). In
Vect_delete(), I have replaced unlink() with remove(), working on Linux,
awaits testing on Windows.

Markus M

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

GDAL · April 20, 2011, 8:00am

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

Replying to [comment:25 mmetz]:
> Replying to [comment:23 marisn]:
> > I changed bug summary to better reflect it's scope.
> >
> > It affects also v.in.ogr removal of temporary files (coor and not hist
file). Bug #1303
>
> Hopefully fixed for devbr in r46041.

tested with WinGRASS-6.5.SVN-r46045-1-Setup.exe

{{{
g.remove vect=mygeology@user1
Removing vector <mygeology@user1>
Unable to delete file 'J:\gisdata/nc_spm_08/user1/vector/mygeology/hist'.
Reason: Permission denied
couldn't be removed
<mygeology> nothing removed
(Wed Apr 20 09:59:46 2011) Command finished (0 sec)
(Wed Apr 20 09:59:47 2011)
g.remove vect=mygeology@user1
Removing vector <mygeology@user1>
(Wed Apr 20 09:59:48 2011) Command finished (0 sec)
}}}

Helmut

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

GDAL · April 20, 2011, 2:09pm

#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:25 mmetz]:

> Hopefully fixed for devbr in r46041.
>
> Vect_delete() uses unlink(), whereas raster and all other files are
removed by remove(): the file will remain in existence until the last file
descriptor referring to it is closed (at least on Linux). In
Vect_delete(), I have replaced unlink() with remove(), working on Linux,
awaits testing on Windows.

I'm fairly sure that r46041 has no effect. On Unix, the difference between
remove() and unlink() is that remove() handles both files and directories;
it calls unlink() for files and rmdir() for directories. unlink() only
works on files.

The "garbage-collecting" behaviour (a file is removed when it has no links
and no process has it open) always applies. There is no way to force
deletion of a file which is open, or to remove all links to a file (there
may exist links in directories on which the process lacks write
permission, in directories which are inaccessible due to having another
filesystem mounted over them, etc).

On Windows, I can't discern any difference between unlink() and remove().
Unlike Unix, remove() only works for files. And unlike Unix, you can't
"unlink" a file which is open; the unlink/remove call fails with EACCESS.

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

GDAL · April 20, 2011, 2:38pm

#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:27 glynn]:
> Replying to [comment:25 mmetz]:
>
> > Hopefully fixed for devbr in r46041.
> >
> > Vect_delete() uses unlink(), whereas raster and all other files are
removed by remove(): the file will remain in existence until the last file
descriptor referring to it is closed (at least on Linux). In
Vect_delete(), I have replaced unlink() with remove(), working on Linux,
awaits testing on Windows.
>
> I'm fairly sure that r46041 has no effect. On Unix, the difference
between remove() and unlink() is that remove() handles both files and
directories; it calls unlink() for files and rmdir() for directories.
unlink() only works on files.
>
> The "garbage-collecting" behaviour (a file is removed when it has no
links and no process has it open) always applies. There is no way to force
deletion of a file which is open, or to remove all links to a file (there
may exist links in directories on which the process lacks write
permission, in directories which are inaccessible due to having another
filesystem mounted over them, etc).
>
> On Windows, I can't discern any difference between unlink() and
remove(). Unlike Unix, remove() only works for files. And unlike Unix, you
can't "unlink" a file which is open; the unlink/remove call fails with
EACCESS.

None of the files making up a native GRASS vector should be still open
when they are to be deleted. Some of them may have been opened and closed
recently (a few lines of code further up in Vect_delete()), but I am
pretty sure that they are all closed, otherwise g.remove should never
work. Maybe fclose() does not close a file stream now, but sometime soon
(e.g. busy flushing buffers), and 'soon' is sometimes too late?

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

GDAL · April 21, 2011, 12:14pm

#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:28 mmetz]:

> None of the files making up a native GRASS vector should be still open
when they are to be deleted.

I know that they '''shouldn't''' be open, but are they? See comment:3.

> I am pretty sure that they are all closed, otherwise g.remove should
never work.

But g.remove '''doesn't''' work.

Well, it works on Unix, as it's perfectly valid to remove a file which is
open (remove() and unlink() just remove the filename; the file itself will
be removed once there are no more links and no process has it open).

And it works on Windows if you use it to remove a half-deleted map. In
this case, the history file never gets opened in the first place.

But it doesn't work on Windows if you try to remove a valid map.

> Maybe fclose() does not close a file stream now, but sometime soon (e.g.
busy flushing buffers), and 'soon' is sometimes too late?

No; fclose() doesn't return until the underlying file is actually closed.
Lots of code would break if this wasn't the case, as it's quite common to
delete or rename a file immediately after fclose() (on Windows, you can't
rename an open file).

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

GDAL · April 21, 2011, 3:36pm

#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:29 glynn]:
> Replying to [comment:28 mmetz]:
>
> > None of the files making up a native GRASS vector should be still open
when they are to be deleted.
>
> 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.

These changes should IMHO first be done in trunk, then backported.

> > I am pretty sure that they are all closed, otherwise g.remove should
never work.
>
> But g.remove '''doesn't''' work.

... on the first run on Windows when using the wxGUI. BTW, it '''does'''
work for me just fine on Windows using the !TclTk GUI.
>
> Well, it works on Unix, as it's perfectly valid to remove a file which
is open (remove() and unlink() just remove the filename; the file itself
will be removed once there are no more links and no process has it open).
>
> And it works on Windows if you use it to remove a half-deleted map. In
this case, the history file never gets opened in the first place.
>
> But it doesn't work on Windows if you try to remove a valid map.
>
IOW, if Vect_close() is called before the files are to be removed.

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

GDAL · April 21, 2011, 3:48pm

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

Replying to [comment:30 mmetz]:
> 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.

it's already in trunk [source:grass/trunk/lib/vector/Vlib/open.c#L165]

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

GDAL · April 21, 2011, 3:49pm

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

Replying to [comment:31 martinl]:
> Replying to [comment:30 mmetz]:
> > 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.
>
> it's already in trunk [source:grass/trunk/lib/vector/Vlib/open.c#L165]

...only referring to Vect!__open_old()

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

GDAL · April 21, 2011, 3:55pm

#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:32 martinl]:
> Replying to [comment:31 martinl]:
> > Replying to [comment:30 mmetz]:
> > > 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.
> >
> > it's already in trunk [source:grass/trunk/lib/vector/Vlib/open.c#L165]
>
> ...only referring to Vect!__open_old()

Unfortunately, G_zero() does not set all contents of the Map_info
structure to 0 or NULL; that's the reason for the existence of line 180 in
open.c [grass/trunk/lib/vector/Vlib/open.c#L180]

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

GDAL · April 22, 2011, 3:55pm

#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: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.

> Unfortunately, G_zero() does not set all contents of the Map_info
structure to 0 or NULL

How come?

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

GDAL · May 12, 2011, 8:55am

#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>

GDAL · May 14, 2011, 1:50am

#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>

Helena_Mitasova4 · May 14, 2011, 3:09am

I have compiled freshly downloaded GRASS7 (from svn trunk)
on a new Mac (to have something to work with in Prague)
and I am getting the error below when wxGUI tries to start
(the historical map shows up but it does not get to open the GIS manager
window).
On the same machine I have compiled the GRASS6.4.1 source provided by
William and the wxGUI runs OK and I have GRASS7 compiled on March 26
running successfully on another Mac.

Any idea what is wrong here? This seems to be different from #1362

thanks, Helena

GRASS 7.0.svn (gisdemo_ncspm):~ > Traceback (most recent call last):
  File
"/Users/melanka/grass7svn/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
line 1612, in <module>
    sys.exit(main())
  File
"/Users/melanka/grass7svn/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
line 1605, in main
    app = GMApp(workspaceFile)
  File
"/Users/melanka/grass7svn/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
line 1505, in __init__
    wx.App.__init__(self, False)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py",
line 7913, in __init__
    self._BootstrapApp()
  File
"/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py",
line 7487, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File
"/Users/melanka/grass7svn/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
line 1548, in OnInit
    workspace = self.workspaceFile)
  File
"/Users/melanka/grass7svn/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
line 150, in __init__
    BestSize((self.toolbars['tools'].GetSize())))
  File
"/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/aui.py",
line 751, in AddPane
    return self._AddPane1(window, info)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/aui.py",
line 620, in _AddPane1
    return _aui.AuiManager__AddPane1(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at
../src/aui/framemanager.cpp(941) in AddPane(): A pane with that name
already exists in the manager!

martinl · May 14, 2011, 7:50am

Hi Helena,

2011/5/14 <hmitaso@ncsu.edu>:

Any idea what is wrong here? This seems to be different from #1362

not related, please try out r46260. Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

GDAL · August 26, 2011, 12:43pm

#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>