[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupt
Linda A. Walsh
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Tue, 15 Nov 2011 12:46:23 -0800
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199) Gecko/20100228 Lightning/0.9 Thunderbird/188.8.131.52 Mnenhy/0.7.6.666
Paul Eggert wrote:
A) catch INT (& catchable signals), and remove any files that are
That might cause trouble in other cases. For example, "cp A B" where
B already exists.
Am **only** suggesting this where 'B' has already been opened
and truncated by stuff being copied from 'A'...
The point is to not leave a 'B' that is *indeterminate*.
In this case it's unwise to remove B if interrupted
-- people won't expect that.
Better than leaving *doo doo* in a file where they expect
And in general 'cp' has behaved the way
that it does for decades, and we need to be careful about changing its
default behavior in such a fairly-drastic way.
It's a bug...Fixing a bug isn't usually considered
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.
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions, Linda A. Walsh, 2011/11/15