bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions

[Linda A. Walsh]

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

   =====
   A A A  Um...yeah, you could try to apply the idea in general, but it
   might not have
   unforeseen side effects like you are demonstrating.A A  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.A
   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!)...A  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.