rename("symlink-to-dir/", "name") behavior

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know that draft 4 added some clarification on rename(2) (and mv(1))
behavior on path resolution.  However, there is still an ambiguous
situation, which I don't see documented, and I would like some consensus
before writing an aardvark.  This issue was raised as a report against GNU
coreutils: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343652.  Consider:

$ mkdir A
$ ln -s A B
$ mv B/ C

On at least Solaris and and FreeBSD, the call resolves B/ to the name A,
finds that it is a directory, and moves the directory to the new name C.
This is somewhat surprising to novice users, since B still exists, but is
now a broken link.  On Linux, the call recognizes that B is a symlink
(even though the trailing slash would resolve to a directory), and fails
with ENOTDIR.

My strict reading of the current wording in draft 4 does not permit Linux'
behavior (even though it is more useful, in my opinion), since the
trailing slash on B/ means that the old argument names a directory by the
rewritten path resolution rules in XBD 4.12 (line 3008).  Do we want to
support both behaviors, or even add an additional restriction at line
56800 (and thus make the current Solaris and FreeBSD implementation
buggy), that for rename, an 'old' argument with a trailing slash must be a
directory (and not a symlink to a directory)?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHm3zS84KuGfSFAYARAqLQAJ0WnR+89JfM/deFcdSJ1oy84tq1KACfctmu
wEjo+2fwORPoM78Jn5snOps=
=EBwm
-----END PGP SIGNATURE-----