On Tue, Sep 20, 2011 at 2:30 PM, Berthier, Emmanuel < emmanuel.berth...@intel.com> wrote:
> This is a real Sqlite error, in http://www.sqlite.org/c3ref/c_abort.html, > there is: > #define SQLITE_IOERR 10 /* Some kind of disk I/O error > occurred */ > This error occurs when a seek()/read() call fails. > > That's why I've analyzed the journal file and decoded its header: the page > nb differ from the real page stored in the journal. So, seek() generates a > kind of "out of file" error. > seek() allows one to seek past the end of the file, so the problem is not with seek (unless sqlite3's VFS interface castrates it), but probably a follow-up read() after the seek. It is perfectly legal, generically speaking, to fseek(f,100,SEEK_END) followed by a write() (which would grow the file, permissions allowing). > I think it's a real issue between Sqlite and FS. > Sqlite has huge constraints against FS behavior: > ...barrier=1 and do not disable the write cache so most Linux distributions are vulnerable to this problem. Note that this is an operating system and hardware issue and that there is nothing that SQLite can do to work around it. Other database engines have also run into this same problem." But notice those last two sentences. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
