Thomas Hood <[EMAIL PROTECTED]> wrote: > Zygo Blaxell originally wrote in Oct 1999: >> 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. > > > Zygo Blaxell recently wrote: > [...] >> 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
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. >> 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. :-( > > Jim Meyering: Is this correct? It is true that if rename fails, mv must copy then remove -- which means we lose atomicity. >> 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. This would be nice, but it has a fatal flaw: If mv is killed between the link and unlink, then it has the unacceptable side effect of leaving the source and dest. linked. >> 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. That is a good idea. I'd welcome a complete patch (ChangeLog, texinfo docs (including justification) unified diffs, and test case(s)). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
