GNU bug report logs - #10055
cp: cp -u corrupts 'fs'' information if interupted; can't

Previous Next

Full log

View this message in rfc822 format

From: "Linda A. Walsh" <law <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10055 <at> debbugs.gnu.org
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

Paul Eggert wrote:


> 
>> A) catch INT (& catchable signals), and remove any files that are
>> 'incomplete'
> 
> 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
drastic.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.