[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupt
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Tue, 15 Nov 2011 12:23:57 -0800
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0
Thanks for your thoughtful suggestions.
I like many of the ideas and hope that somebody can find the time
to code them up. Here are some more-detailed comments.
On 11/15/11 11:07, Linda Walsh wrote:
> 3). use posix_fallocate (if available) to allocate sufficient space for the
This seems like a good idea, independently of the other points.
That is, if A and B are regular files, "cp A B" could
use A's size to preallocate B's storage, and it could
fail immediately (without trashing B!) if there's not
enough storage. I like this.
> 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. In this case it's unwise to remove B if interrupted
-- people won't expect that. 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.
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.
> B) 1). open destination name for write (verifying accesses) w/
> Exclusive Write;
This could be another new option, though (as you write) it's
orthogonal to the main point. I would suggest that this option be
called --oflag=excl (by analogy with dd's oflag= option). We can add
support for the other output flags while we're at it, e.g.,
> 2). open tmp file for actual cp operation.
> 5); rename tmp over original; (closing original before rename on systems
> that don't support separation of names and FD's (Win systems et al).
Yes, that could be another option. I see (2) and (5) as being the
same feature. Perhaps --remove-destination=after?
> C) reset DT stamps on newly opened files to '0' (~1969/70?)'
I dunno, this kind of time stamp munging sounds like it'd cause more
trouble than it'd cure. It's more natural (and easier to debug
failures) if the last-modified time of a file is the time that the
file was last modified.
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions, Linda A. Walsh, 2011/11/15