chrysn wrote: > Package: coreutils > Version: 8.4-2 > Severity: important > > when files are created inside a directory during a `mv` of a the > directory, those files are deleted at the end of the move. > > this typically happens when moving large (in terms of amount of data) > directories across file systems. > > to reproduce, you need a current directory on a different partition than > your `/tmp`, then do > > $ mkdir /tmp/movetest > $ mkdir movetest > $ dd if=/dev/zero of=movetest/bigfile bs=1024 count=300000 > 300000+0 records in > 300000+0 records out > 307200000 bytes (307 MB) copied, 11.4315 s, 26.9 MB/s > > (it is important that the file is big enough to take some seconds to > create and read) > > $ mv movetest /tmp/movetest/ &; sleep 3; echo foobar > movetest/latefile > [1] + done mv movetest /tmp/movetest/ > $ ls -lamovetest > ls: cannot access movetest: No such file or directory > $ ls -la /tmp/movetest > total 300348 > drwxr-xr-x 2 chrysn chrysn 4096 Apr 13 12:21 . > drwxrwxrwt 158 root root 45056 Apr 13 12:21 .. > -rw-r--r-- 1 chrysn chrysn 307200000 Apr 13 12:21 bigfile > > you see that the `latestfile` has vanished. > > no such behavior is documented in the man page. > > i suggest that `mv` should only delete the files it has successfully > moved, and then should behave like `rmdir` for removing the directories. > > i'm indifferent on whether it should just print a warning that some > folders could not be removed because they are not empty and return > successfully or set a non-zero exit status. > > (there could be flags to modify the behavior, eg one to restore the old > behavior and one to make mv fail if the directories can't be removed.)
Thanks for the report. In some sense, the behavior you've noticed is inevitable. Imagine that after copying, mv were to go back and check again: then it spots the new file (your "latestfile") and copies it. Do we continue iterating and looking for new files in each and every directory being copied? At some point we have to stop and then begin the removal process (which requires removal of each entire tree/argument). Between when we stop looking for new files and when the removal gets to any given directory, there will always be an interval during which someone can create a file/dir there that will silently be removed. Also consider this: what if a file we've already copied is removed before the copy completes? Should mv perform another iteration to detect that, and then remove it also in the destination tree? If we were to try to make mv remove source files only if we've copied them, not only would that introduce a significant amount of overhead, but it would change mv's semantics. If you want to pursue this, I suggest that you bring it up with the Austin Group (they define the POSIX standard). http://www.opengroup.org/austin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
