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

[L A Walsh]

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