> 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...
do you mean you add the sqlite library, load the file and then use sqlite to read/write data to a database instead of a text or bin file? I like it...
I do simulations in physics and we're really not familiar with these types of things.
Some extra time to learn SQL but it will save you a lot of time in the long run.
Another benefit compared to ASIC is that you get: File compression, easy to access random parts of the file and fast (random) inserts.