[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupt

From: Linda A. Walsh
Subject: bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Date: Tue, 15 Nov 2011 12:46:23 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

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
some.thing valid.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]