bug#34681: mv fails when renaming on external drive in coreutils 8.30-2

[Pádraig Brady]

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.
> 
> address@hidden:~# ./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
> address@hidden:~#

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