> Also in the write/sync/rename workflow, what happens if the temp file is on a separate filesystem?
In the write/sync/rename workflow, this is never supposed to occur. The temp file must always be on the same filesystem as the real file for the atomic-rename guarantee to apply.
Naturally, this can be extremely difficult to achieve in some cases. The file may be a symlink, which must be fully resolved to a symlink-free path to determine the real filesystem. The file may be the target of a bind mount, in which case I doubt there is any portable way to determine which filesystem it came from. And there there's the possibility that you can write to the file, but not the directory _containing_ the file...
The write/sync/rename process is hardly an ideal way to implement atomic replacement semantics. There are simply too many potential points of failure.
Posted Jan 25, 2012 20:38 UTC (Wed) by droundy (subscriber, #4559)
[Link]
> The write/sync/rename process is hardly an ideal way to implement atomic replacement semantics. There are simply too many potential points of failure.
True, but it's also the only one we've got, right?