Re: coreutils-5.94 imminent

[Eric Blake]

-----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             address@hidden
-----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-----