This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in rmdir(2)


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

The fix to rmdir(2) is easy - check for a trailing / or /. or /..
before handing the name off to the complex path processing
code, and fail with EINVAL if so.  rmdir(2) isn't called often
enough for this to slow down everything else, and there are
no Windows API calls in this failure mode, and in return you
get POSIX compliance.

--
Eric Blake



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]