[Thought I send out rspns to this, but can't find it in my outgo, so...recomposing/sending,
sorry for delay)
On 11/15/11 12:46, Linda A. Walsh wrote:

  
    Better than leaving *doo doo* in a file
    
Sometimes, but not always.  I can think of plausible cases where I'd
rather have a partial copy than no copy at all.  As an extreme example,
if I'm doing 'cp /dev/tty A', I do not want A removed on interrupt
even if A has already been truncated and overwritten,
as A contains the only copy of the data that I just typed in by hand.
=====
    Um...yeah, you could try to apply the idea in general, but it might not have
unforeseen side effects like you are demonstrating.   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'.

In that case, you get interrupt, and you end up with a truncated file in Dst, that has
some (not even the DT of the src file, but the DT the file was opened (or more likely
closed) DateTime that will guarantee, that a correct copy will never get updated
over the now, destroyed, bogus copy. 

Not only that, but weeks later, when you go though your backup dir, and wonder
why some file 'x' is only 1/10th the size of the rest of the similar backups, .... your
original can be very gone...(not that 1 of the multiple other backups might not sub-in, but
that's not the point!)...  You don't want the partially copied update -- that has already
destroyed an original, to now leave a turd in place so that no future cp -uav will correct
the problem....

Though, (I'm sure you'd love to see this in 'cp', (*cough*), 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...

Actually that might not be a bad idea...


But we could add an option to 'cp' to have this behavior.
Perhaps --remove-destination=signal?  That is --remove-destination
could have an optional list of names of places where the destination
could be removed, where the default is not to remove it, and
plain --remove-destination means --remove-destination=before.
      
----
    I think you misunderstood the problem.
    
Perhaps I did.  But could you explain the problem then?  For example,
how would the proposed "cp --remove-destination=signal A B"
not address the problem?

Well, if it were the default case, sure, but if default is to trash files, that's bad.