mv attempts to move directories when rename() fails. This causes code which relied on the old behavior to determine whether files existed on the same filesystem to fail in horrible ways. There should either be an option to request this new behavior, or an option to disable it.
Can this wish report be closed now? Or are you still wishing for this feature? I presume, at least, that the scripts that broke because of the change in mv's behavior eventually got fixed. :)
I am still wishing for this feature. It's been a long wait so far. ;-) old scripts. My new scripts don't use mv at all--they usually include a Perl one-liner to invoke the rename() system call. There's two cases of note: one where the source is a directory (so mv copies the directory and attempts to remove the original), and one where the source is a file but the file is in an unwritable directory (so mv copies this file as in the directory case). The latter case is especially annoying since the removal of the original file always fails, leaving me with two copies to clean up. The latter case occurs quite often for me when trying to 'mv' a file owned by another user from /tmp to somewhere else--the old 'mv' would have given up after the rename() system call fails, the new 'mv' acts like 'cp' but with more error messages. The behavior seems to be mandated by some standards organization--everybody's mv seems to have this annoying behavior now, not just GNU's. :-( If 'mv' *must* have this behavior, it would be preferable if it tried these in order: 1. rename(filea, fileb). If successful exit. 2. link(filea, fileb) followed by unlink(filea). If successful exit. 3. if and only if the error from the link was "invalid cross-device link", copy (filea, fileb) followed by unlink(filea) (possibly using recursive directory-copying code as mv does now). If successful exit. 4. Exit with an error. I would prefer to have an option for a "no-copy mode", where mv does everything it does now, except that it gives up if it is forced to try to copy anything.
I am still wishing for this feature. It's been a long wait so far. ;-) old scripts. My new scripts don't use mv at all--they usually include a Perl one-liner to invoke the rename() system call. There's two cases of note: one where the source is a directory (so mv copies the directory and attempts to remove the original), and one where the source is a file but the file is in an unwritable directory (so mv copies this file as in the directory case). The latter case is especially annoying since the removal of the original file always fails, leaving me with two copies to clean up. The latter case occurs quite often for me when trying to 'mv' a file owned by another user from /tmp to somewhere else--the old 'mv' would have given up after the rename() system call fails, the new 'mv' acts like 'cp' but with more error messages. The behavior seems to be mandated by some standards organization--everybody's mv seems to have this annoying behavior now, not just GNU's. :-( If 'mv' *must* have this behavior, it would be preferable if it tried these in order: 1. rename(filea, fileb). If successful exit. 2. link(filea, fileb) followed by unlink(filea). If successful exit. 3. if and only if the error from the link was "invalid cross-device link", copy (filea, fileb) followed by unlink(filea) (possibly using recursive directory-copying code as mv does now). If successful exit. 4. Exit with an error. I would prefer to have an option for a "no-copy mode", where mv does everything it does now, except that it gives up if it is forced to try to copy anything.
Zygo Blaxell originally wrote in Oct 1999: Zygo Blaxell recently wrote: [...] Jim Meyering: Is this correct? -- Thomas Hood
Thomas Hood <jdthood@yahoo.co.uk> wrote: I cannot reproduce that. Here's what I tried, as a non-root user, using mv from coreutils-5.93: $ mv /tmp/.X0-lock /var/tmp/j mv: cannot move `/tmp/.X0-lock' to `/var/tmp/j': Operation not permitted [Exit 1] $ ls -l /tmp/.X0-lock /var/tmp/j ls: /var/tmp/j: No such file or directory -r--r--r-- 2 root root 11 Dec 19 04:13 /tmp/.X0-lock [Exit 2] If you can reproduce it, please be sure to let us know the types of file systems and (OS) involved. Also, please run mv under strace and include its output. It is true that if rename fails, mv must copy then remove -- which means we lose atomicity. If mv is killed between the link and unlink, then it has the unacceptable side effect of leaving the source and dest. linked. That is a good idea. I'd welcome a complete patch (ChangeLog, texinfo docs (including justification) unified diffs, and test case(s)).
I wrote: Actually, I *can* reproduce it, of course. The above system didn't have separate partitions for /tmp and /var. If they're separate, you do end up with a copy in both source and destination. One could make an argument for removing the destination in this case, but I think that would be a little too surprising.
You filed the bug http://bugs.debian.org/48038 in Debian BTS against the package fileutils. I'm closing it at *unstable*, but it will remain open for older distributions. I was unable to find a bug that explains the reason for its removal, but it appears to have been superceded by coreutils (which is an essential package) on Mon, 30 Sep 2002 12:24:37 -0400. I have decided not forward these bugs to coreutils, since a lot could have been changed in these 8 years. If your issue is still reproducible or still valid, do not hesitate to reopen and reassign it or reply to this email. Don't hesitate to reply to this mail if you have any question. Thank you for your contribution to Debian.