How to Corrupt an SQLite Database File

In another life (2007) I worked for a company that does digital signage. We had about 8000 systems deployed across the US. The software on them relied heavily on SQLite. At some point we started seeing random corrupted SQLite databases. Trying to figure out what was causing this we realized our pc manufacturer was using the same sku but hardware inside could vary... and in particular the hard drive. Every system with a corrupt DB had a particular brand hard…

I read this as a damnation of POSIX filesystem semantics. File descriptors getting reused, insane locking semantics on close, allowing you to delete an open file and providing no means to prevent it, fork causing problems, unspecified behavior of sync() (is it barrier or "full" sync). Though: Multiple copies of SQLite linked into the same application. Weird and rare scenario, but why not keep the global list of open sqlite files in a global shared memory segment?

I believe that SQLite is a continous source for awe in terms of overall quality of software. Their documentation is spot on, extremely clear and has a very low barrier for entry. Applauds to them and the fantastic job they have been doing in the last decades.

> suppose a multi-thread process has two or more threads with separate SQLite database connections to the same database file. Then a third thread comes along and wants to read something out of that same database file on its own, without using the SQLite library. The third thread does an open(), a read() and then a close(). One would think this would be harmless. But the close() system call caused the locks held on the database by all the other…