Based on the comments I found trawling through the source, you guys have seen this one coming. mv(1) tries calling rename(2) to begin with, and if that fails and sets errno to EXDEV it falls back to a copy/unlink strategy. The issue of filesystems where rename(2) is not supported has arisen - 9p only supports a rename within the same directory and sets errno to EPERM when a rename across directories is requested, which is in accordance with the notes on EPERM in rename(2) here[1]. So, I've a one line patch below that causes mv(1) to try a bit harder when rename fails and errno is EPERM.
[1] man-pages-2.43 from http://www.win.tue.nl/~aeb/linux/man/ --- src/copy.c 2007/01/03 12:43:18 1.1 +++ src/copy.c 2007/01/03 12:43:44 @@ -1431,7 +1431,7 @@ where you'd replace `18' with the integer in parentheses that was output from the perl one-liner above. If necessary, of course, change `/tmp' to some other directory. */ - if (errno != EXDEV) + if (errno != EXDEV && errno != EPERM) { /* There are many ways this can happen due to a race condition. When something happens between the initial XSTAT and the _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
