On 10/29/2016 10:44, Simon Slavin wrote:
To minimise problems like the one you reported it needs to quit the program (preferably with a non-zero exit code) when it gets any unexpected result.
This particular application, SQLite QSettings backend, can't quit on the disk-full condition because the condition can be, and is often transient. Quitting will also potentially mean losing the data when it could have been saved later.
I'm not certain that this would have completely prevented the problem you reported, but repeated attempts to make changes to a database with no free space aren't going to lead to anything good. Another factor is whether you had free space when you tried to open the database after the faults. Each time you use the SQLite API to open a database SQLite checks for to see if it was closed correctly last time. If not, it tries to recover an uncorrupted database. [1] But if the disk is full this will fail. Though it shouldn't lead to further corruption. [1] I don't know whether it checks to see whether there is space free first.
My program only issues deletes to mirror the in-app map deletions. So I am very confident it didn't just delete all records.
This leaves SQLite/OS. The system with disk-full shut down, this caused the signal to the app, this caused some failed attempts to update some rows in the SQLite table, then the system has shut down. The question is what zeroed the file.
It is possible that the disk-full interjects in between some open/read/write operations, so that some of them succeed and some subsequent ones fail, leaving something in unexpectedly wrong state.
Yuri _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
