Atomic update of destination in cp and install

[Markus Kuhn]

It appears the coreutils "install" tool makes no effort to update
the destination file atomically. In other words, "install" is
currently not a safe tool to update an existing file if the
destination might be in use concurrently.

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.

The "install" command on Mac OSX 10.9 has an option -S to
make the overwriting of the destination atomic.

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.

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?

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

Markus

--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain