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

[Paul Eggert]

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.