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
