[GRASS-dev] Re: remove(dir) fails on Windows

[Glynn Clements]

Roger Bivand wrote:

> > > > remove() directory fails on Windows so that vectors cannot be deleted
> > > > without error. Patch for lib/vector/Vlib/map.c is attached.
> > > > IMPORTANT!
> > >
> > > Much worse is that a vector open in QGIS cannot be deleted.
> > > Open file on Windows cannot be deleted nor moved.
> > > That is very bad because it is very common to run a module
> > > again and again and watch results on display.
> > > I don't have any idea what could be done.
> > 
> 
> http://www.mkssoftware.com/docs/man3/remove.3.asp
> 
> says that:
> 
> Windows NT/2000/XP/2003 does not let you delete a directory if a user has a lock
> on it. Any user that is in that directory has a lock on it. All locks to a
> directory must be resolved before remove() on a directory can be successful.
> 
> There are also indications that the directory should also be empty, from rmdir():
> 
> The rmdir() function removes an empty directory whose name is given by pathname.
> The directory must not have any entries other than dot (.) and dot-dot (..).
> 
> If the directory's link count becomes zero and no process has the directory open
> or locked, the directory space is freed and the directory is no longer
> accessible. If one or more processes have the directory open or locked (for
> example, by having the directory as the current working directory), rmdir()
> fails and sets errno to EBUSY. 
> 
> Is this what is going on here?

AFAICT, in his follow-up, Radim was talking about deleting files.

Unlike Unix, Windows won't let you delete a file which is open in any
process, or a directory which is the current directory for any
process.

On Unix, unlink/rmdir simply remove the entry from the parent
directory. The file/directory isn't actually deleted until no process
is using it.

Anything which relies upon the Unix semantics for unlink/rmdir won't
work on Windows, either natively or using Cygwin. This is one aspect
of Unix which Cygwin doesn't attempt to emulate.

-- 
Glynn Clements <glynn at gclements.plus.com>