bug#47059: (bug in cp removing destination file when it can't be replaced due to cross-volume linking)

[L A Walsh]

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