-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Jim Meyering on 9/18/2009 4:47 AM: > Assuming ln -s /nowhere dangling-symlink, > New behavior: > > $ ./readlink -fv dangling-symlink/ > /nowhere > > Previous: > > $ readlink -fv dangling-symlink/ > readlink: dangling-symlink/: No such file or directory > [Exit 1]
On one hand: ln -s dangling link => 0 stat dangling/ => ENOENT stat link/ => ENOENT mkdir link/ => 0 the behavior is consistent - a single mkdir can create the lone missing element in the (expanded) pathname. If we really claim that -f implies that a missing last element is acceptable if it can be created by the same name, then that explains the new behavior. On the other hand, continuing the above example, there are some Linux interfaces which distinguish between a dangling symlink with trailing slash compared to a missing file with trailing slash: rmdir link/ => ENOTDIR rmdir dangling/ rmdir dangling/ => ENOENT rmdir link/ => ENOTDIR This difference does not exist on Solaris (which follows the counter-intuitive POSIX rule that the first 'rmdir link/' remove dangling rather than fail with ENOTDIR). So, we need to decide whether I should work on changing the CAN_ALL_BUT_LAST mode to explicitly differentiate between a missing element with a trailing slash (ok) compared to an existing but dangling symlink with a trailing slash (fail, as before this change); or whether the behavior on a dangling symlink with a trailing slash is an intentional change for consistency. Once we make that decision, we either need to patch coreutils' NEWS or I need to fix the regression in gnulib canonicalize. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqzcGgACgkQ84KuGfSFAYCX/gCdFt1ja3jSK+lNjaxjGXsRRwqD Ly0AoKNQr+/DhFU9cTMPftrQxnlNmD3e =cQPt -----END PGP SIGNATURE-----