Not clear on need for fsync and sync.
Are those for networked like NTFS or just as security against crashes.
Logically on a single system there would be no effect assuming error free filesystem operation. Unless I'm missing something.
Are those for networked like NTFS or just as security against crashes.
Logically on a single system there would be no effect assuming error free filesystem operation. Unless I'm missing something.
ext4 on Linux (since 2009) special-cases rename() when overwriting an existing file so that it works safely even without fsync() (https://lwn.net/Articles/322823/), but that is not guaranteed by all other implementations and filesystems.
The sync() at the end is indeed not needed for the atomicity, it just allows you to know that after its completion the rename will not "roll back" anymore on a crash. IIRC you can also use fsync() on the parent directory to achieve this, avoiding sync() / syncfs().
This is interesting.
The linked git entry (https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.g...) from the LWN article says "Notice: this object is not reachable from any branch."
Did this never get merged because I definitely saw this issue in production well after 2009.
I guess it either got changed, or, a different patch applied but perhaps this https://github.com/torvalds/linux/blob/master/fs/ext4/namei.... does it?
And yes, the code you highlighted is exactly this special-case in its current form. The mount option "noauto_da_alloc" can be used to disable these software-not-calling-fsync safety features.
The final sync is just there for durability, not atomicity, like you say.
Correct.
The rename can succeed while the write of the file you just renamed gets rolled back.