Dear folks, I have a setup where an app creates a single-user SQLite database by opening a connection, uses it for a number of complicated things, closes the connection, then deletes the database before quitting. The data which goes into this database is highly sensitive and it's very important that my app deletes all files which might contain this data (journal, temp index, etc.) before my application quits.
For the purposes of this question, you can assume SQLite version 3.8.0 or later, that my app never crashes (because I am JUST THAT GOOD), and that if a file is deleted using remove()/unlink() the disk space it was in is not recoverable, e.g. it is immediately overwritten with random bits and other anti-forensic stuff. You can also assume that if a fault is caused by a bug in the operating system, or by malfunctioning hardware, or by the user resetting the hardware while my app is running, that's not my problem. I used to solve this problem by creating a special folder to contain the database. After the connection to the database was severed it would delete the folder. This worked perfectly. Unfortunately an update to the underlying operating system means that my app is allocated one folder to work in and cannot create subfolders. The good parts of this change are that no other app can access files stored in that folder, and that the 'temp folder' is a subfolder of this folder. So my procedure has changed to this: 1) Set the journal mode to DELETE 2) Do a SELECT command because sometimes this forces (1) to happen. 3) Close the database connection, checking the value returned 4) Delete the database file 5) Generate an error if database file still exists 6) Quit The operating system guarantees that if an app quits or crashes, all its file handles are closed and all pending deletes for those files happen. Assuming no hardware/OS faults is it possible for any other SQLite-created files to still exist ? Journal ? Temp index ? Shared memory ? Anything ? I have read <https://www.sqlite.org/tempfiles.html>. Simon.
