file-intro page 13: is rename() actually atomic?

Question

file-intro page 13: is rename() actually atomic?

shdown opened this issue 4 years ago · comments

Victor Krapivensky commented 4 years ago

On page 13 of chapter 39 “INTERLUDE: FILES AND DIRECTORIES” the following is said:

One interesting guarantee provided by the rename() call is that it is
(usually) implemented as an atomic call with respect to system crashes;
if the system crashes during the renaming, the file will either be named
the old name or the new name, and no odd in-between state can arise.
Thus, rename() is critical for supporting certain kinds of applications
that require an atomic update to file state.

However, it is usually not crash-safe.

https://danluu.com/deconstruct-files/ (see the “Rename” subsection of “FAQ” section)

This trick doesn't work. People seem to think that this is safe becaus the POSIX spec says that rename is atomic, but that only means rename is atomic with respect to normal operation, that doesn't mean it's atomic on crash. This isn't just a theoretical problem; if we look at mainstream Linux filesystems, most have at least one mode where rename isn't atomic on crash. Rename also isn't guaranteed to execute in program order, as people sometimes expect.

The most mainstream exception where rename is atomic on crash is probably btrfs, but even there, it's a bit subtle -- as noted in Bornholt et al., ASPLOS’16, rename is only atomic on crash when renaming to replace an existing file, not when renaming to create a new file. Also, Mohan et al., OSDI’18 found numerous rename atomicity bugs on btrfs, some quite old and some introduced the same year as the paper, so you want not want to rely on this without extensive testing, even if you're writing btrfs specific code.

The Linux man page on rename(2) has the following to say:

If newpath already exists, it will be atomically replaced, so there is no point at which another process attempting to access newpath will find it missing. However, there will probably be a window in which both oldpath and newpath refer to the file being renamed.