11–20 of 45 posts
I had recent SQLite corruption, and I suspect it was this - I was accessing an SQLite database from the same python process using both the builtin sqlite3 package, and also the third party apsw library
Article date is Jan 2022. This changes when SQLite runs as WASM in a browser — a context that only became properly viable with OPFS synchronous access handles in mid-2022.
Interesting that it doesn't specifically call out Anti-Virus scanning (which does occasionally result in at least one of these scenarios). I've seen many SQLite database become corrupted and the best you can do is have a backup.
Interesting that it doesn't specifically call out Anti-Virus scanning (which does occasionally result in at least one of these scenarios). I've seen many SQLite database become corrupted and the best you can do is have a backup.
if processes lock the file shouldn't AV refrain from reading or even writing it?
Interesting that it doesn't specifically call out Anti-Virus scanning (which does occasionally result in at least one of these scenarios). I've seen many SQLite database become corrupted and the best you can do is have a backup.
Turns out it was kaspersky intercepting network calls, and deciding it was a very dangerous piece of file, and it would truncate it completely silently.
After wasting a non-billable afternoon on it, I just disabled the antivirus out of desperation and figured it out.
The solution was to generate a self signed certificate and TLS the connection and prevent the bugger to MITM us.
Since this day, even on a local network with behind a proxies and using a VPN, I still use https for all the services if I'm allowed.
Kind of crazy that this is an issue in modern operating systems. There are just so many ways to avoid this obvious footgun of an API design. stdin/out/err should be reserved file descriptors. In fact, why reuse file descriptors at all? Just count up.