bug#10054: [sr #107876] ISSUE: (Unverifyed Bug in 8.13).

[Pádraig Brady]

On 11/15/2011 07:06 PM, Linda Walsh wrote:
> 
> 
> Seems like 'cc' didn't work...
> 
> 
> 
> -------- Original Message --------
> Subject:     [sr #107876] ISSUE: (Unverifyed Bug in 8.13).
> Date:     Tue, 15 Nov 2011 18:28:13 +0000
> From:     Linda A. Walsh <address@hidden>
> To:     Linda A. Walsh <address@hidden>
> 
> 
> 
> URL:
>  <http://savannah.gnu.org/support/?107876>
> 
>                 Summary: ISSUE: (Unverifyed Bug in 8.13).
>                 Project: GNU Core Utilities
>            Submitted by: law
>            Submitted on: Tue Nov 15 10:28:11 2011
>                Category: None
>                Priority: 5 - Normal
>                Severity: 3 - Normal
>                  Status: None
>                 Privacy: Public
>             Assigned to: None
>        Originator Email:             Open/Closed: Open
>         Discussion Lock: Any
>        Operating System: None
> 
>    _______________________________________________________
> 
> Details:
> 
> it appears from the change log, that a bug was introduced in 8.13.
> 
> The Comment was:
> 
> cp -au (where --preserve=links is implicit) may now replace newer
> files in the destination, to mirror hard links from the source.

We thought this was the lesser of two evils.
It would be better to avoid the above behavior of course.

> ====
> 
> However, in copying the files on the target, if the files are NOT linked in 
> the destination, then
> it would seem we have the case where we start with
> src:
> a <=> b
> 
> dest
> 
> a (dup of a src), b (newer file than src) ; broken links;
> 
> 
> 
> ----
> 
> Then correct action (if it behaves this way, fine, but it doesn't sound like
> it)...
> 
> if -u flag is used, we only update newer file items...
> 
> so, after a cp -au, the above condition would remain
> exactly the same.

agreed

> Unless, if 'a' was updated (and thus, 'b' is also "updated to be newer than
> target "b"), then
> src-b would overwrite dst-b

right, that case is ok at present

> if a updated, but has time < dst 'b', then 'b'
> 'a' should not create an older, linked version of 'b', in place of a newer 'b'
> on the destination.

agreed, but implementation is tricky.
I hadn't the time to see if this was possible,
and I've now less time.
Tests are in place though to check changes in this area.

> if 'b' on the src is updated (thus 'a' is updated as well by being linked),
> and 'b' is newer than dst-b), then
> the linked relationship would be copied to the dst (both
> a+b copied and linked).

right, that case is ok at present

> But the key here is that an updated 'a' linked to 'b' on src,
> shoudln't overwrite, recreate a link to b on dst IF dst-b is NEWER than the
> 'b' that would be created.

Yep, this is the awkward case.

> i.e. while -a says to preserve links, in the presense of -u, one would expect
> the newest copies to remain on the dst, as forcing a link in *all* cases, 
> would break the semantics of "-u".
> 
> i.e. use of -u should override -a-'s keep links...(warning/verbose or maybe
> some 'message on exception'...

Maybe someone could have a look.
I saw nothing obvious to address the issue.
The original discussion was at:
http://bugs.gnu.org/8419

cheers,
Pádraig.