[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupt
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Tue, 15 Nov 2011 22:08:31 -0800
Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
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
> 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?
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions, Linda A. Walsh, 2011/11/15