GNU bug report logs - #34681
mv fails when renaming on external drive in coreutils 8.30-2

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34681 in the body.
You can then email your comments to 34681 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Derek Dongray <derek <at> inverchapel.me.uk>
To: bug-coreutils <at> gnu.org
Subject: mv fails when renaming on external drive in coreutils 8.30-2
Date: Wed, 27 Feb 2019 22:20:05 +0000

[Message part 1 (text/plain, inline)]

When trying to use mv to rename a file on an external drive using coreutils
8.30-2 on a debian system (Linux version 4.19.0-3-amd64), the rename fails
with the error message:

    mv: cannot move 'file1' to a subdirectory of itself 'file2'

Downgrading to coreutils 8.30-1, the rename executes as expected.

The following is the result of running a test script. The folder '/backup'
is an external drive using the ZFS fileystems (zfs-zed 0.7.12-3), but I
have seen a report on superuser.com (
https://superuser.com/questions/1409618/renaming-a-file-with-mv-cannot-move-to-a-subdirectory-of-itself)
that this also happens with NTFS external drives.

root <at> capella:~# ./mv-bug
+ apt install -y --allow-downgrades coreutils=8.30-1
Reading package lists... Done
Building dependency tree
Reading state information... Done
coreutils is already the newest version (8.30-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+ cd /backup
+ touch t
+ ls s t
ls: cannot access 's': No such file or directory
t
+ mv t s
+ ls s t
ls: cannot access 't': No such file or directory
s
+ rm s t
rm: cannot remove 't': No such file or directory
+ cd /root
+ apt install -y coreutils=8.30-2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  coreutils
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,707 kB of archives.
After this operation, 4,096 B disk space will be freed.
Get:1 http://ftp.uk.debian.org/debian sid/main amd64 coreutils amd64 8.30-2
[2,707 kB]
Fetched 2,707 kB in 1s (2,729 kB/s)
apt-listchanges: Reading changelogs...
(Reading database ... 226704 files and directories currently installed.)
Preparing to unpack .../coreutils_8.30-2_amd64.deb ...
Unpacking coreutils (8.30-2) over (8.30-1) ...
Setting up coreutils (8.30-2) ...
Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...
Processing triggers for man-db (2.8.5-2) ...
+ cd /backup
+ touch t
+ ls s t
ls: cannot access 's': No such file or directory
t
+ mv t s
mv: cannot move 't' to a subdirectory of itself, 's'
+ ls s t
ls: cannot access 's': No such file or directory
t
+ rm s t
rm: cannot remove 's': No such file or directory
root <at> capella:~#

[Message part 2 (text/html, inline)]

Message #8 received at 34681 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Derek Dongray <derek <at> inverchapel.me.uk>, 34681 <at> debbugs.gnu.org,
 915559 <at> bugs.debian.org, josch <at> debian.org
Subject: Re: bug#34681: mv fails when renaming on external drive in coreutils
 8.30-2
Date: Wed, 27 Feb 2019 22:56:29 -0800

On 27/02/19 14:20, Derek Dongray wrote:
> When trying to use mv to rename a file on an external drive using coreutils
> 8.30-2 on a debian system (Linux version 4.19.0-3-amd64), the rename fails
> with the error message:
> 
>     mv: cannot move 'file1' to a subdirectory of itself 'file2'
> 
> Downgrading to coreutils 8.30-1, the rename executes as expected.
> 
> The following is the result of running a test script. The folder '/backup'
> is an external drive using the ZFS fileystems (zfs-zed 0.7.12-3), but I
> have seen a report on superuser.com (
> https://superuser.com/questions/1409618/renaming-a-file-with-mv-cannot-move-to-a-subdirectory-of-itself)
> that this also happens with NTFS external drives.
> 
> root <at> capella:~# ./mv-bug
> + apt install -y --allow-downgrades coreutils=8.30-1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> coreutils is already the newest version (8.30-1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> + cd /backup
> + touch t
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + mv t s
> + ls s t
> ls: cannot access 't': No such file or directory
> s
> + rm s t
> rm: cannot remove 't': No such file or directory
> + cd /root
> + apt install -y coreutils=8.30-2
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be upgraded:
>   coreutils
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 2,707 kB of archives.
> After this operation, 4,096 B disk space will be freed.
> Get:1 http://ftp.uk.debian.org/debian sid/main amd64 coreutils amd64 8.30-2
> [2,707 kB]
> Fetched 2,707 kB in 1s (2,729 kB/s)
> apt-listchanges: Reading changelogs...
> (Reading database ... 226704 files and directories currently installed.)
> Preparing to unpack .../coreutils_8.30-2_amd64.deb ...
> Unpacking coreutils (8.30-2) over (8.30-1) ...
> Setting up coreutils (8.30-2) ...
> Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...
> Processing triggers for man-db (2.8.5-2) ...
> + cd /backup
> + touch t
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + mv t s
> mv: cannot move 't' to a subdirectory of itself, 's'
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + rm s t
> rm: cannot remove 's': No such file or directory
> root <at> capella:~#

That sounds like unsupported renameat2()
is not falling back to rename()

The only change in debian is:
  coreutils (8.30-2) unstable; urgency=medium
    * Use renameat glibc function that can be intercepted by fakechroot
      (Closes: https://bugs.debian.org/915559 )
    * Above requires autoreconf turned on again

A quick scan of the patches shows that the name was changed
to renameatu() in gnulib, but copy.c still calls renameat2()
and thus now doesn't have the fallback.

To be clear this seems to only be an issue in the debian patch.

cheers,
Pádraig

Message #15 received at 34681 <at> debbugs.gnu.org (full text, mbox):

From: Johannes Schauer <josch <at> debian.org>
To: 34681 <at> debbugs.gnu.org, 915559 <at> bugs.debian.org, Pádraig Brady <P <at> draigBrady.com>, Derek Dongray <derek <at> inverchapel.me.uk>
Subject: Re: bug#34681: mv fails when renaming on external drive in coreutils
 8.30-2
Date: Thu, 28 Feb 2019 08:48:20 +0100

[Message part 1 (text/plain, inline)]

Quoting Pádraig Brady (2019-02-28 07:56:29)
> That sounds like unsupported renameat2() is not falling back to rename()
> 
> The only change in debian is:
>   coreutils (8.30-2) unstable; urgency=medium
>     * Use renameat glibc function that can be intercepted by fakechroot
>       (Closes: https://bugs.debian.org/915559 )
>     * Above requires autoreconf turned on again
> 
> A quick scan of the patches shows that the name was changed
> to renameatu() in gnulib, but copy.c still calls renameat2()
> and thus now doesn't have the fallback.
> 
> To be clear this seems to only be an issue in the debian patch.

seems to be a duplicate of #923420

[signature.asc (application/pgp-signature, inline)]

Message #18 received at 34681 <at> debbugs.gnu.org (full text, mbox):

From: Johannes Schauer <josch <at> debian.org>
To: 34681 <at> debbugs.gnu.org, 915559 <at> bugs.debian.org, P <at> draigBrady.com,
 derek <at> inverchapel.me.uk
Subject: Re: bug#34681: mv fails when renaming on external drive in coreutils
 8.30-2
Date: Thu, 28 Feb 2019 09:11:54 +0100

[Message part 1 (text/plain, inline)]

Quoting Pádraig Brady (2019-02-28 07:56:29)
> That sounds like unsupported renameat2()
> is not falling back to rename()
> 
> The only change in debian is:
>   coreutils (8.30-2) unstable; urgency=medium
>     * Use renameat glibc function that can be intercepted by fakechroot
>       (Closes: https://bugs.debian.org/915559 )
>     * Above requires autoreconf turned on again
> 
> A quick scan of the patches shows that the name was changed
> to renameatu() in gnulib, but copy.c still calls renameat2()
> and thus now doesn't have the fallback.
> 
> To be clear this seems to only be an issue in the debian patch.

seems to be a duplicate of #923420

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.