This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: bug in rmdir(2)
At 06:26 PM 9/28/2005, you 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.
>
>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.
Sure, this is reasonable for rmdir(). I don't think it is for all paths
though, which was the implication of your opening statement.
--
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/