GNU bug report logs -
#47059
bug in cp removing destination file when it can't be replaced due to cross-volume linking
Previous Next
Full log
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 3 years and 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.