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

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Tue, 15 Nov 2011 19:09:02 UTC

Severity: wishlist

Full log


Message #17 received at 10055 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Linda A. Walsh" <law <at> tlinx.org>
Cc: 10055 <at> debbugs.gnu.org
Subject: Re: bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information
	if interupted; can't recover on future invoctions
Date: Tue, 15 Nov 2011 13:07:36 -0800
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.

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




This bug report was last modified 6 years and 245 days ago.

Previous Next


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