Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199910262347.QAA27059@aleph.ssd.hal.com>
Subject: Re: cygwin's unlink
To: cygwin AT sourceware DOT cygnus DOT com
Date: Tue, 26 Oct 1999 16:47:59 -0700 (PDT)
In-Reply-To: <19991026165225.A2485@cygnus.com> from "Chris Faylor" at Oct 26, 99 04:52:25 pm
From: "J. J. Farrell" <jjf AT bcs DOT org DOT uk>
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text

> From: Chris Faylor <cgf AT cygnus DOT com>
> 
> On Tue, Oct 26, 1999 at 02:01:10PM -0600, Steve Jorgensen wrote:
> >Anyway, in the case where the file is truely a directory, under all
> >unix systems we've tried, unlink returns and error, and we proceed with
> >the recursive directory removal, but under cygwin it returns success
> >(even though nothing is removed), and our code returns success without
> >removing the directory.  Is this a limitation in the underlying windows
> >unlink, or a bug in cygwin?
> 
> When I try this I get a "Permission denied" error.  It should be a
> "Is a directory error" though.  I've changed the sources here so
> this should be fixed in the next snapshot.

Before you fix that (he says, probably too late) ...

This one's a bit complex. First off: under POSIX.1 it is
implementation-defined whether or not unlink() works on
directories. This means that Steve's algorithm is wrong,
since what he saw as a bug in cygwin's unlink() is perfectly
valid behaviour for a POSIX.1 system. The fact that POSIX
allows it suggests that at least one UNIX implementation
behaved that way when POSIX.1 was drawn up, and future ones
are allowed to if they wish (though rmdir() is the preferred
interface).

Secondly: in the case where the implementation does not
support unlink() on directories, the required error value
is EPERM which would result in a "Permission denied" error.
From the XPG3 documentation (which is aligned with POSIX.1):

 [EPERM] The file named by path is a directory, and either
         the calling process does not have appropriate
         privileges, or the implementation prohibits using
         unlink() on directories.

I can't comment on why Steve and Chris saw different results,
but both were equally valid (assuming in Steve's case that the
directory entry would have disappeared once everything below
it had been unlinked). The implementation may support unlink()
of directories, and if it doesn't it should give EPERM.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com