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
View this message in rfc822 format
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.
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.