Joey Hess afb3e3e472 avoid crash when starting fsck --incremental when one is already running ... Turns out sqlite does not like having its database deleted out from underneath it. It might suffice to empty the table, but I would rather start each fsck over with a new database, so I added a lock file, and running incremental fscks use a shared lock. This leaves one concurrency bug left; running two concurrent fsck --more will lead to: "SQLite3 returned ErrorBusy while attempting to perform step." and one or both will fail. This is a concurrent writers problem.		2015-02-17 13:30:24 -04:00
..
Fsck.hs	avoid crash when starting fsck --incremental when one is already running	2015-02-17 13:30:24 -04:00
Handle.hs	show error when sqlite crashes worker thread	2015-02-17 13:03:57 -04:00
Types.hs