GNU bug report logs - #10055
cp: cp -u corrupts 'fs'' information if interupted; can't

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Linda A. Walsh" <gnu <at> tlinx.org>
Cc: 10055 <at> debbugs.gnu.org
Subject: bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Date: Tue, 15 Nov 2011 22:08:31 -0800

On 11/15/11 19:33, Linda A. Walsh wrote:
> Why don't we
> focus on the specific problem mentioned which was using it in the context of
> the "-u" flag, (and with -a/-r and/or a wildcard), where you expect it to update
> contents of 'Dst' with 'Src'.

I'd rather not have a heuristic that says "cp removes the destination
when interrupted, if you use the -u flag with -a or -r or a wildcard".
That'd be a hard rule to remember, and it's probably not the "best"
rule anyway, for somebody's opinion of "best".  We need a simple rule
that's easy to document and to remember, even if it isn't necessarily
the "best" by some other measure.

It'd be OK if "cp -a" implies the new --remove-destination=signal
(or whatever) option.  Then you could just use "cp -a".

> cp could check file sizes and see
> if the target is smaller and if so.. assume, if the DT's were equal that the file cp was
> interrupted...and finish it...

I'm still not convinced by the idea about trusting the time stamp on
the destination.  Every time 'cp' writes to its destination, it will
update the destination's time stamp.  Sure, 'cp' can use utime immediately
afterwards to alter the time stamp, but there's still a window where
the destination's time stamp will be 'now'.  In general 'cp' must
continue to work in that case -- so why should it bother to reset the
destination's time stamp after every write?

Previous Next

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