Re: Atomic update of destination in cp and install

[Bob Proulx]

Markus Kuhn wrote:
> A destination file D can be updated atomically by
> 
>   1) first writing the new content of the destination file
>      into a temporary file T (e.g. created with mkostemp()),
>      located in the same directory as D, then
> 
>   2) rename T into D (which atomically replaces D on most
>      Unix-style file systems)
> 
> This way, concurrent users of D will only be able to open
> complete versions of either the old or the new D, but never
> see any intermediate state, such as a missing D or a half
> written one. Likewise, if the operation fails, the old D
> will remain intact.
> ...
> It would be nice if the GNU variants of "cp", "install"
> and "mv" (the latter also has to copy if the destination
> is on a different device) would also offer the ability to
> update destination files atomically.

Note that the 'rsync' command (which never says "no" to an additional
option or feature [chuckle]) behaves this way by default.  If you have
the rsync command available, and most systems do, then you can use it
to get the behavior you desire.  It is already implemented there as
the default behavior.

> I'm not even sure why this should just be an option:
> can you think of a good reason why such atomic
> updates should not be the default behaviour?

It changes the inode number.  People expecting the inode number to
remain the same but only to have the file contents updated will always
see the inode change when using the write-to-temporary and then
rename-into-place strategy done.

It requires write capability to the directory holding the file.  The
current behavior of truncating and then copying on top of the target
file does not require write capability to the directory since the
inode is not changed therefore the directory file is not changed.
Writing the file off to the side in a temporary file and then renaming
it into place requires write access to the directory holding the file.

Writing the file off to the side and renaming it into place breaks
hard links to the file that are located in other directories.

All of those things have strong effects on the overall system.  Okay
if the author expects it.  Not okay if they don't.

> Surely the increased robustness far outweighs the cost of
> an additional rename.

I see the heart of the issue as being a change in decades old
behavior.  Change is always disruptive.  When the change is to
something fundamental like this it is always something to be very
cautious about.  Something that just seems very simple will
fundamentally break many others.

I think that simple commands such as 'cp' should definitely not do
this by default.  And neither should it be added as an option because
that is feature creep.  Since this is always possible to do this
yourself with mktemp, cp and mv.

More complex command such as 'install' people expect to be more
complex.  I think having this as an option to install could be useful.
Since the entire purpose of 'install' is as a command for use in
"installing" files.  So I am 50/50 neutral for whether it should be
available in 'install'.

Bob