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

Previous Next

Package: coreutils;

Reported by: L A Walsh <coreutils <at> tlinx.org>

Date: Wed, 10 Mar 2021 21:42:01 UTC

Severity: normal

Tags: moreinfo

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 47059 <at> debbugs.gnu.org
Subject: bug#47059: bug in cp removing destination file when it can't be replaced due to cross-volume linking
Date: Mon, 21 Feb 2022 01:18:43 -0800
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.