-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Phillip Susi on 2/13/2006 11:55 AM: > Shouldn't it be made consistent? IMHO, the command "mv a b/" means move > the file or directory named a into the directory named b, so if b does > not exist or is not a directory, it should fail. If you want to make mv > deviate from this behavior, then at least shouldn't it behave the same > on all platforms, without depending on the implementation of rename()?
Read the earlier thread. The gist was that when a is a directory, and b does not exist, you get the first synopsis form of rm(1) from POSIX, (http://www.opengroup.org/onlinepubs/009695399/utilities/mv.html), which states that you defer to the result of rename("a", "b/") in step 2. The problem is that rename(2) is underspecified, so it is not obvious whether moving a directory to a name that obviously denotes another directory should succeed or fail; the argument was that coreutils should succeed if the underlying system call can succeed until such time as POSIX is improved to fully specify rename(2). Speaking of which, consider this ambiguity in POSIX: $ ln -s nowhere/ broken $ mkdir /tmp/dir $ mv -f /tmp/dir nowhere This must succeed when . and /tmp are on different file systems (since in step 2, rename(2) fails with EXDEV, you fall through to step 4 which deletes the broken link before replacing it in step 5 with the directory), but what about when . and /tmp are on the same file systems (or when rename(2) can preserve hard links across file systems)? The POSIX rules for rename(2) state both: "If the old argument points to the pathname of a directory, the new argument shall not point to the pathname of a file that is not a directory." and "If the new argument points to a pathname of a symbolic link, the symbolic link shall be removed." So which rule applies here - must rename remove the symbolic link and replace it with the directory, or fail with ENOTDIR? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8dqk84KuGfSFAYARAtg+AKDBlGp/BtGuVjSSwk4Y3cHMKCPgfwCdGHEn QQO+SlsoHPFkVao2bzZ0tVU= =9/Fz -----END PGP SIGNATURE----- _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
