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