On almost all Linux filesystems, ext3, ext4 (with default options), btrfs, etc, the rename is guaranteed to be committed to disk only after the file blocks are written. You will be guaranteed after a crash to either have the old file, or the new file.
The use of fsync at one time was a bit of a stop-gap measure to force correct ordering of the write operations (as a side-effect), but it's not needed these days, and can be a problem in some rare cases. There's a big performance hit on some file systems (eg. ext3) because it will cause a flush of all unrelated file blocks too, which could take several seconds, holding your process hostage.
If you're only concerned with making sure the file blocks are written before the rename is written, but not that it is done right away
, the fsync is completely unnecessary. Those old ext4 docs where it asserts that apps that don't use fsync are "broken" is quite incorrect, which is why it was later patched to guarantee the expected behavior.
fsync can block for a very long time:
Windows is another story. One must use MoveFileEx with MOVEFILE_REPLACE_EXISTING, or there are some newer API calls if you don't need to run on XP. Not sure if NTFS needs a sync on the temp file before the move or not, but probably not.