> If newpath already exists, it will be atomically replaced, so that there is no point at which another process attempting to access newpath will find it missing.
More: https://sqlite.org/howtocorrupt.html , https://sqlite.org/tempfiles.html
Typical (mis)behavior includes correctly-sized files that consist partially or entirely of zero bytes (because NTFS does guarantee newly-allocated space will be zero-filled).
Nevertheless, I agree with you, and, therefore, when dealing with application-managed files (as opposed to user-visible documents) on local NTFS filesystems, I typically
1. Write to a temporary file filename.temporary, say.
2. FlushFileBuffers
3. Rename the original file to e.g., filename.original.
4. Rename the temporary file to the original filename.
5. Delete filename.original.
Then, in some thread-safe manner at some point before accessing any such files — at application startup, say, when performance permits — I remove lingering ".temporary" files and restore any orphaned ".original" files to their original filenames.
This, of course, assumes FlushFileBuffers works properly, so, in particular, still fails in the presence of storage devices, drivers, and configurations (e.g., "Turn off Windows write-cache buffer flushing") that break buffer flushing, which are not nearly as rare as they should be.
On *nix you need to sync before renaming as well.
0: https://github.com/laurent22/joplin/blob/805a5399b5288b4a282...