3 ms·

I hear there is quite some complexity in sqlite to work around quirks of the file system API, in order to avoid data loss, yet there are still ways this can hap

I hear there is quite some complexity in sqlite to work around quirks of the file system API, in order to avoid data loss, yet there are still ways this can happen: https://sqlite.org/howtocorrupt.html https://sqlite.org/howtocorrupt.html It's a bad sign if you have to repair the shortcomings of a lower layer in your application.

mmt 8y ago
How many of those characteristics identified on that page are really shortcomings rather than, as the parent comment says, freedom-enhancing (if not performance-enhancing) features? The workarounds seem to have more to do with SQLite's use as an embedded library than with filesystem behavior. All of section 1 is about rogue overwriting. Absent a particularly fine-grained filesystem permission model, or enforced locking. The former might only have "freedom" implications without any performance penalty, but perhaps not the latter. Section 2 is about locking, so see above. Even if it's advisory, that just moves any slowdown from the kernel to the application. Of course, broken locking is clearly a shortcoming, and this is one of the quirkiest (maybe newest?) aspects of the filesystem. If anything qualifies under the "bad sign" characterization, this does. However, it's also not exactly fundamental to the filesystem, as even section 2.3 describes what SQLite will do if POSIX adivsory locking is not supported over NFS (i.e. it is possible for locking to be unavailable). The remaining sections all appear to be about bugs, either hardware, thread library, elsewhere in the kernel, SQLite itself, or in configuration/usage (disabling corruption protections).