GNU bug report logs - #47059
bug in cp removing destination file when it can't be replaced due to cross-volume linking

Previous Next

To reply to this bug, email your comments to 47059 AT debbugs.gnu.org.

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

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Coreutils <bug-coreutils <at> gnu.org>
Subject: bug in cp removing destination file when it can't be replaced due
 to cross-volume linking
Date: Wed, 10 Mar 2021 13:41:05 -0800

Was trying to save disk space by linking duplicate
files, in a dir. 
FWIW, my 'cp', is aliased to 'cp --preserve=all'

>  for f in Roboto*.ttf;do
cp -l /usr/share/fonts/TTF/$f .
>  done
cp: cannot create hard link './Roboto-Bold.ttf' to 
'/usr/share/fonts/TTF/Roboto-Bold.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Italic.ttf' to 
'/usr/share/fonts/TTF/Roboto-Italic.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Light.ttf' to 
'/usr/share/fonts/TTF/Roboto-Light.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Medium.ttf' to 
'/usr/share/fonts/TTF/Roboto-Medium.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Regular.ttf' to 
'/usr/share/fonts/TTF/Roboto-Regular.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoCondensed-Bold.ttf' to 
'/usr/share/fonts/TTF/RobotoCondensed-Bold.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoCondensed-Light.ttf' to 
'/usr/share/fonts/TTF/RobotoCondensed-Light.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoCondensed-Regular.ttf' to 
'/usr/share/fonts/TTF/RobotoCondensed-Regular.ttf': Invalid cross-device 
link
cp: cannot create hard link './RobotoSlab-Bold.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Bold.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoSlab-Light.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Light.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoSlab-Regular.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Regular.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoSlab-Thin.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Thin.ttf': Invalid cross-device link
----
   Well that didn't work, guess I'll copy over the affected files.

   Repeating command w/o "-l":

Ishtar:…/3.1.16055.164_0> for f in Roboto*.ttf
do
cp -l /usr/share/fonts/TTF/$f .
done
Ishtar:…/3.1.16055.164_0> ll Roboto*
ls: cannot access 'Roboto*': No such file or directory
---
Huh?...all of the files were deleted!

That's not good.  When creating a link to a local file, I
first create the link to a temporary name to ensure I have
appropriate access (or that its not cross-linked in this
case).  Apparently 'cp' doesn't exercise the same caution.
It seems 'cp' deletes the target first (as
it was linked to some other file), but then can't
perform the requested copy-link, so leaves the
target location with no file at all.

Um...not good.
Is this fixed in a newer core utils version?
coreutils-8.23-2.3.2.x86_64

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#47059: (bug in cp removing destination file when it can't
 be replaced due to cross-volume linking)
Date: Thu, 11 Mar 2021 11:23:28 -0800

Did anyone see this?  Usually someone says something like
confirming it or asking for more info.

Is this a known bug and/or has it been seen before?

(slightly cleaned up report below)

Thanks!

On 2021/03/10 13:41, L A Walsh wrote:
> Was trying to save disk space by linking duplicate files, in a dir. 
> FWIW, my 'cp', is aliased to 'cp --preserve=all'
> 
>>  for f in Roboto*.ttf;do > cp -l /usr/share/fonts/TTF/$f .; done
> cp: cannot create hard link './Roboto-Bold.ttf' to 
> '/usr/share/fonts/TTF/Roboto-Bold.ttf': Invalid cross-device link
> …
> cp: cannot create hard link './RobotoSlab-Thin.ttf' to 
> '/usr/share/fonts/TTF/RobotoSlab-Thin.ttf': Invalid cross-device link
> ----
>     Well that didn't work, guess I'll copy over the affected files.
>
>     Repeating command w/o "-l":
>
> Ishtar:…/3.1.16055.164_0> for f in Roboto*.ttf; do 
> cp /usr/share/fonts/TTF/$f . ; done
> cp: cannot access '/usr/share/fonts/TTF/Roboto*.ttf': No such file or directory
> ---
> Huh?...all of the files were deleted!
>
> That's not good.  When creating a link to a local file, I
> first create the link to a temporary name in the same directory
> to ensure I have appropriate access (or that its not cross-linked
> as in this case).  Apparently 'cp' doesn't exercise the same caution.
> It seems 'cp' deletes the target first (as it was linked to some
> other file), but then can't perform the requested copy-link, so
> leaves the target location with no file at all.
>
> Is this fixed in a newer core utils version?
> coreutils-8.23-2.3.2.x86_64

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 47059 <at> debbugs.gnu.org
Subject: Re: bug#47059: bug in cp removing destination file when it can't be
 replaced due to cross-volume linking
Date: Mon, 21 Feb 2022 01:18:43 -0800

I can't reproduce the problem with either coreutils 8.23 or 9.0. 
Unfortunately, the original bug report does not have a recipe for 
reproducing the problem from scratch, without having access to your 
system. If you could come up with the a self-contained way to reproduce 
the problem with current coreutils, that would be helpful.

> When creating a link to a local file, I
> first create the link to a temporary name to ensure I have
> appropriate access (or that its not cross-linked in this
> case).  Apparently 'cp' doesn't exercise the same caution.

Actually, cp -l is even more cautious than the procedure you describe. 
If the destination already exists, cp -l fails without altering the 
destination.

$ echo a >abc
$ echo bb >/tmp/def
$ cp -l abc /tmp/def
cp: cannot create hard link '/tmp/def' to 'abc': File exists
$ ls -l abc /tmp/def
-rw-rw-r-- 1 eggert eggert 3 Feb 21 01:13 /tmp/def
-rw-rw-r-- 1 eggert eggert 2 Feb 21 01:13 abc

Hence the symptoms you reported are mysterious; I don't see how they 
could have happened.

Previous Next

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