[PATCH v2] Cygwin: rmdir: fail if last component is a symlink, as on Linux

Eric Blake eblake@redhat.com
Tue Sep 24 20:12:00 GMT 2019

On 9/24/19 2:28 PM, Ken Brown wrote:

>> Looks okay to me.
> Thanks.  Does the "intentionally ignoring POSIX" part apply to rmdir also?  I 
> didn't find it easy to decipher POSIX.
> Even for mkdir, POSIX says, "If path names a symbolic link, mkdir() shall fail 
> and set errno to [EEXIST]."  See 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html#tag_16_325.
> But I'm not clear on how POSIX decides whether "path names a symbolic link" in 
> the case where the last component is a symlink followed by a slash.

POSIX says that "/path/to/symlink" names a symlink, but
"/path/to/symlink/" (attempts to) name the directory at the contents of
the symlink.  In mkdir("/path/to/symlink/", if symlink is dangling, then
the official result is to create an empty directory at the target of the
symlink, so that symlink is no longer dangling.  In
rmdir("/path/to/symlink/"), if an empty directory exists at that
location, the directory must be removed leaving symlink dangling.

The POSIX rules are self-consistent and match what Solaris does, but it
is surprising action-at-a-distance.  Linux kernel developers have
repeatedly stated that they are unwilling to implement that behavior,
and would much rather have mkdir("/path/to/symlink/") fail with EEXIST
(the dangling symlink exists, and we can't create a directory to replace
it, nor will we create a directory to make the symlink non-dangling),
and similarly rmdir("/path/to/symlink/") fail because symlink is not a
directory, even though symlink/ resolves to a directory.

So even though we are knowingly violating POSIX, having both functions
be consistent with Linux is reasonable.  (I still hope that POSIX will
relax its stance to allow both Solaris AND Linux behaviors, but that's
not going to happen any time soon...)

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20190924/65db395c/attachment.sig>

More information about the Cygwin-patches mailing list