Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <433BE840.30301@byu.net>
Date: Thu, 29 Sep 2005 07:12:32 -0600
From: Eric Blake <ebb9@byu.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: bug in rmdir(2)
References: <092820052226.6432.433B18B2000A598D0000192022007358340A050E040D0C079D0A@comcast.net> <20050929075025.GA19713@calimero.vinschen.de> <433BDB6D.1010806@byu.net> <20050929123102.GA23334@calimero.vinschen.de>
In-Reply-To: <20050929123102.GA23334@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 9/29/2005 6:31 AM:
> 
> Try the actual call rmdir(2) and especially read the rmdir entry in SUSv3:
> http://www.opengroup.org/onlinepubs/009695399/functions/rmdir.html

That's exactly what I did before first raising my report.

> 
> There's no text restricting the behaviour in case of "dir/", there's just
> this:
> 
>   If the path argument refers to a path whose final component is either
>   dot or dot-dot, rmdir() shall fail.

But the confusion in POSIX comes from the overriding requirement that for
all functions, unless otherwise specified, a filename with a trailing
slash has . implicitly appended:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
And since rmdir(2) does not specify otherwise, the strict reading says it
should treat "dir/" as "dir/.", which must fail.

> 
> On Linux, rmdir(2) consequentially allows removing "dir/".

So Linux is not strictly compliant, because it strips the trailing slash
instead of appending . (although my argument to the Austin group is that
Linux's behavior is desirable, and the spec is buggy and should be fixed;
not that Linux should be changed).  So that same argument applies to
cygwin - let rmdir("dir/") continue to work as though it had been
rmdir("dir"), and hope that the POSIX folks agree on a fix to the standard
that allows the reasonable existing behavior.

You are still left, however, with a decision of whether rmdir("symlink/")
would fail with ENOTDIR or remove the referrant directory.  If I
understood the coreutils thread correctly (I don't have access to the
various kernels myself to verify), Linux 2.4.x removes the referrant, but
Linux 2.6.x fails with ENOTDIR.  I would lean towards the latter, as it
can be rather confusing when the referrant directory is removed, leaving a
dangling symlink.

> 
> The "path/.." case is also already covered by returning ENOTEMPTY or
> EBUSY, whatever Windows returns.  So there's only the "path/." case
> left to check.

True - ENOTEMPTY or EBUSY are both allowed by POSIX in that case (cygwin
actually gets ENOTEMPTY).

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDO+hA84KuGfSFAYARAitbAJ40X0SPZBJVowMgmlrxiseLNPJqSgCgnm0t
KcRwGS+BNI6saKppoU+3vLU=
=YRz8
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/