Subject: Re: bug#8419: cp -au : New hard links in source becomes new files at destination when using cp -au

From: Jim Meyering <[email-masked]>
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".
...