coreutils-6.4: mv(1), rename(2) and 9p

[sqweek]

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