Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 28 Sep 2005 19:02:31 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: bug in rmdir(2)
Message-ID: <20050928230231.GF26582@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <092820052031 DOT 26647 DOT 433AFDB9000034B50000681722073000330A050E040D0C079D0A AT comcast DOT net> <6 DOT 2 DOT 1 DOT 2 DOT 0 DOT 20050928163815 DOT 044348e0 AT pop DOT prospeed DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.1.2.0.20050928163815.044348e0@pop.prospeed.net>
User-Agent: Mutt/1.5.8i

On Wed, Sep 28, 2005 at 04:46:45PM -0400, Larry Hall wrote:
>At 04:31 PM 9/28/2005, you wrote:
>>POSIX requires resolving a filename with a trailing slash as
>>though . were implicitly present, and requires rmdir(2) to fail
>>with EINVAL if the final component is '.'.  Therefore, both of
>>these cases should fail rather than removing the directory:
>>
>>$ mkdir a b
>>$ rmdir a/ b/.
>>$ ls a b      # Oops, rmdir("a/") and rmdir("b/.") incorrectly succeeded
>>ls: a: No such file or directory
>>ls: b: No such file or directory
>
>
>But that conflicts with Windows semantics, doesn't it?  If this is important 
>enough for 'rmdir', I suppose you could patch it to give you the behavior 
>you describe.  But making Cygwin work this way internally is playing with
>the already complex path processing code.  I can't see the gain to support 
>this corner case and slow down everything else.

LARRY!  LARRY!  It's POSIX!  It's POSIX, I tell you man!  Are you daft?
We don't argue with POSIX!

cgf

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