bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions

[Pádraig Brady]

On 11/15/2011 08:23 PM, Paul Eggert wrote:
> 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
>> copy
> 
> 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.

I'll take a look at this at some stage.
I was intending to do it right after the fiemap stuff
as it was quite related, but that needed to be bypassed
for normal copies. Anyway I'll bump fallocate
up my priority list.

> 
>> 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.  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.,
> --oflag=excl,append,noatime.
> 
>>   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?

There are lots of implementation issues with tmp files,
many of which are noted here:
http://www.pixelbeat.org/docs/unix_file_replacement.html

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

Not a bad idea and least invasive, but if the Ctrl-C happened
between the creat() and utime() you'd get a newer zero length file.
Then subsequent `cp -u` would have to treat zero length files specially.

cheers,
Pádraig.