> How do you protect yourself against incomplete writes?
I don't update files on disk in-place. I write to a new file, and once it's done I do an atomic move and replace the old file with the new one.
> What about when there's a critical update that you don't want lost?
I immediately write it to the disk? (:
I don't think it's possible to completely avoid this problem. In a traditional database if you suddenly lose power you'll also lose that critical update, if it hasn't been yet committed to the disk.
I like the approach of tailoring the app to the use case, so I'm not arguing you should do something differently.
The database has commit for exactly this reason. If you lose power, you will not acknowledge the commit to the client, so the client may retry. For example, the end user may get an error page. This is different from a case when the app would show modified values, but the next day, the modifications would be gone.
With the database, you still have the problem, that after a user sees an error, the transaction might have suceeded. Eg if connection drops at the moment when the DB receives the commit command.
The old version of the application that was written before my version always wrote the entire file like you do. But when the file got very large it was too slow, which was why we used SQLite in newer versions.
I don't update files on disk in-place. I write to a new file, and once it's done I do an atomic move and replace the old file with the new one.
> What about when there's a critical update that you don't want lost?
I immediately write it to the disk? (:
I don't think it's possible to completely avoid this problem. In a traditional database if you suddenly lose power you'll also lose that critical update, if it hasn't been yet committed to the disk.