GNU bug report logs - #8419
cp -au : New hard links in source becomes new files at destination when using cp -au

Previous Next

Package: coreutils;

Reported by: Odd.Harry.Mannsverk <at> benteler-alu.com

Date: Mon, 4 Apr 2011 10:49:01 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #37 received at 8419 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 8419 <at> debbugs.gnu.org
Subject: Re: bug#8419: cp -au : New hard links in source becomes new files
	at	destination when using cp -au
Date: Tue, 26 Jul 2011 12:07:10 +0200
Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 25/07/11 17:26, Pádraig Brady wrote:
>>> Actually I'm wondering now whether the new code
>>> should be unconditionally replacing the dest?
>>> What if the dest is a separate newer file?
>>> I.E. I think the following amended test should pass?
>>> Also what about backups if the separate file is older?
>>
>> Well backups take a different path, as do
>> older or non existing destination paths.
>> So how about this change to just remove
>> the new create_hard_link: call and beef up the test?
>
> Hi Pádraig,
>
> The link-creation code there cannot be removed.
> Consider this scenario:
>
>   src/{a,b}  # a and b are linked
>   dst/src/a
>
> If cp -au encounters src/a first, then the new "remember_copied"
> call records the required info so when it encounters src/b it can
> make the desired link from the preexisting dst/src/a to dst/src/b.
> In that case, the link-creation code is indeed unnecessary.
>
> However, what if it encounters src/b first?
> In that case, it must copy src/b to dst/src/b (new inode!)
> Then, when it encounters src/a, it must *remove* the preexisting dst/src/a

This "must" is my interpretation that --preserve=link (implied
by -a and -p) has a higher priority than the --update (-u) option.

> and replace it with a hard link to dst/src/b.
> As an alternative, cp could conceivably remove the just-copied dst/src/b,
> replacing it with a hard-link to dst/src/a.
>
> The trouble I have with all of this is that we can see two different
> outcomes, depending on the order in which "a" and "b" (in the src
> directory) are processed by cp.  In one case, the preexisting and
> up-to-date dst/src/a is not modified.  In the other, it is removed,
> and replaced by a hard-link to potentially-differing-content "dst/src/b".
...




This bug report was last modified 13 years and 306 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.