Florent Bayle <[EMAIL PROTECTED]> wrote: > Package: coreutils > Version: 5.96-5 > Severity: normal > > To be brief : > [EMAIL PROTECTED]:/tmp# mkdir -p test1/test test2/test; touch > test1/test/file; mv test2/* test1/ > mv: cannot move `test2/test' to a subdirectory of itself, `test1/test' > [EMAIL PROTECTED]:/tmp# > > It seems to be an incorrect error message, but I think that this bug is > related to #376743 because with version 5.94-1 of coreutils, I have this > output : > [EMAIL PROTECTED]:/tmp# mkdir -p test1/test test2/test; touch > test1/test/file; mv test2/* test1/ > mv: cannot overwrite directory `test1/test' > [EMAIL PROTECTED]:/tmp#
Thank you for reporting that. Note that this is file-system dependent for me. On tmpfs, reiserfs, and ext3, my results match yours: $ rm -rf a b; mkdir -p a/t b/t; touch a/t/f; mv b/t a /cu/src/mv: cannot move `b/t' to a subdirectory of itself, `a/t' But on xfs, I get this: $ rm -rf a b; mkdir -p a/t b/t; touch a/t/f; mv b/t a ./mv: cannot move `b/t' to `a/t': File exists Here's where the strace output diverged: $ diff -u /t/strace-xfs /t/strace-tmpfs|grep rename -rename("b/t", "a/t") = -1 EEXIST (File exists) +rename("b/t", "a/t") = -1 ENOTEMPTY (Directory not empty) This is due in part to the following change, since before then, the code in question never had to deal with an existing destination directory. 2006-05-11 Jim Meyering <[EMAIL PROTECTED]> mv -T DIR EMPTY_DIR no longer fails unconditionally * src/copy.c (copy_internal): Don't manually prohibit a move where the destination is an existing directory. Sometimes doing that is valid. Let the rename system call enforce the rules. That is allowed only when the source is a directory and the destination directory (to be replaced) is empty. Reported by Eric Blake. * tests/mv/no-target-dir: New file/test for this. * tests/mv/Makefile.am (TESTS): Add no-target-dir. * NEWS: Mention this. Since today's problem is due to work-around code whose sole purpose is to accommodate buggy rename support in old systems, I'm fixing it by removing the questionable work-around code. I've included the patch for the trunk below. Will probably do the same on the branch. Note that I'm also removing the EIO-handling code. If anyone cares about SunOS-4.1.4 or Irix 5.3 and still has access to such a system, please try the following commands in an NFS-mounted directory, and let me know if you get different results: $ rm -rf a; mkdir a; perl -e 'rename "a","a/x" or die "$!\n"' Invalid argument 2006-07-05 Jim Meyering <[EMAIL PROTECTED]> * src/copy.c (copy_internal): Don't work around old NFS clients like SunOS-4.1.4 and Irix 5.3 that set errno to values like EIO and ENOTEMPTY upon failed rename. Otherwise, we risk misinterpreting a banal failure as a recursive move-into-self failure. Reported by Florent Bayle in <http://bugs.debian.org/376749>. Index: src/copy.c =================================================================== RCS file: /fetish/cu/src/copy.c,v retrieving revision 1.200 diff -u -p -r1.200 copy.c --- src/copy.c 3 Jun 2006 09:04:22 -0000 1.200 +++ src/copy.c 5 Jul 2006 08:38:52 -0000 @@ -1385,18 +1385,7 @@ copy_internal (char const *src_name, cha /* This happens when attempting to rename a directory to a subdirectory of itself. */ - if (errno == EINVAL - - /* When src_name is on an NFS file system, some types of - clients, e.g., SunOS4.1.4 and IRIX-5.3, set errno to EIO - instead. Testing for this here risks misinterpreting a real - I/O error as an attempt to move a directory into itself, so - FIXME: consider not doing this. */ - || errno == EIO - - /* And with SunOS-4.1.4 client and OpenBSD-2.3 server, - we get ENOTEMPTY. */ - || errno == ENOTEMPTY) + if (errno == EINVAL) { /* FIXME: this is a little fragile in that it relies on rename(2) failing with a specific errno value. Expect problems on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]