On 7 May 2017 at 01:39, Dan Kennedy <[email protected]> wrote: > The log most likely won't show too much other than the strerror() text. > > It might be a threads-related error I suppose. I wouldn't jump straight to > that though. > > SQLITE_IOERR_FSYNC means just that - an fsync() call failed. There are > only a couple of reasons for that - invalid file descriptor (some other > module calling close() on our fd?), a real IO error (dodgy phone/SD card, > have you seen this on more than one device?), or perhaps the fd is actually > a socket (hardly seems likely if you got all the way to fsync() without > some other error). >
This is a massive tangent, but for me sqlite's treatment of i/o errors is my least favourite part of the overall design. Because while the extended error code tells you _what_ failed, it doesn't give any information regarding _why_ it failed. The why appears in the log at least (assuming you've configured a callback), but that codepath is logically very separate from the one handling the error which makes it awkward to programatically make decisions about the underlying cause (eg. to give the user an accurate diagnostic -- the difference between "your disk is full" vs "your disk appears broke"). These days (the past 8 years?) at least there's the SQLITE_FCNTL_LAST_ERRNO parameter to sqlite3_file_control() allowing the underlying cause to be introspected, I just feel like it was a mistake to ever mask that cause. I realise no one is asking for my opinion and hindsight is 20/20 so feel free to ignore my musings :) -Rowan _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
