GNU bug report logs - #10054
[cp] 8.13: cp -au may replace newer files [sr #107876]

Previous Next

To reply to this bug, email your comments to 10054 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: [sr #107876] ISSUE: (Unverifyed Bug in 8.13).
Date: Tue, 15 Nov 2011 11:06:21 -0800

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 <INVALID.NOREPLY <at> gnu.org>
To: 	Linda A. Walsh <gnu <at> tlinx.org>



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.


====

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.

Unless, if 'a' was updated (and thus, 'b' is also "updated to be newer than
target "b"), then
src-b would overwrite dst-b
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.

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).


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.

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'...


    
                   




   _______________________________________________________

Reply to this item at:

 <http://savannah.gnu.org/support/?107876>

_______________________________________________
 Message sent via/by Savannah
 http://savannah.gnu.org/

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 10054 <at> debbugs.gnu.org
Subject: Re: bug#10054: [sr #107876] ISSUE: (Unverifyed Bug in 8.13).
Date: Tue, 15 Nov 2011 22:54:38 +0000

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 <INVALID.NOREPLY <at> gnu.org>
> To:     Linda A. Walsh <gnu <at> tlinx.org>
> 
> 
> 
> 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.

Previous Next

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