Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Reply-To: Cygwin List Message-Id: <6.2.1.2.0.20050928163815.044348e0@pop.prospeed.net> Date: Wed, 28 Sep 2005 16:46:45 -0400 To: ericblake AT comcast DOT net (Eric Blake), Cygwin List From: Larry Hall Subject: Re: bug in rmdir(2) In-Reply-To: <092820052031.26647.433AFDB9000034B50000681722073000330A050 E040D0C079D0A@comcast.net> References: <092820052031 DOT 26647 DOT 433AFDB9000034B50000681722073000330A050E040D0C079D0A AT comcast DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/