Hello, This message may be off-topic in that I don't think the following issue corresponds to a bug with SQLite, but it's something I've discovered while using SQLite. Perhaps someone on the list has had a similar experience or could make a suggestion.
A Linux 2.6/x86_64 system reports a "disk I/O error" (SQLITE_IOERR) while generating a specific report from a SQLite database (SQLite 3.3.6). The database and temporary files are accessed through an NFS mount. After running the program again with SQLite tracing enabled (plus a bit more I added), I see that SQLITE_IOERR is returned by unixRead() because read() unexpectedly returned 0! Here's some relevant strace output: open("/nfs/tmp/sqlite_dBjTG5bZdsqFVPb", O_RDWR|O_CREAT|O_EXCL, 0644) = 8 [...] lseek(8, 193536, SEEK_SET) = 193536 write(8, "\n\0\0\0\30\0\222\0\0\266\0\332\0\376\1\"\1F\1l\1\222\1"..., 1024) = 1024 [...] lseek(8, 226304, SEEK_SET) = 226304 write(8, "\n\0\0\0\30\0\240\0\0\240\0\304\0\350\1\f\0010\1T\1x\1"..., 1024) = 1024 lseek(8, 193536, SEEK_SET) = 193536 read(8, "", 1024) = 0 fstat(8, {st_mode=S_IFREG|0644, st_size=227328, ...}) = 0 The read() call shouldn't fail -- the same page was written to at the beginning of the transaction! At least by the time fstat() is called, the file is 227328 bytes long, so a read at an offset of 193536 should not fail. I'm suspecting that the NFS server in question is buggy or misconfigured. Unfortunately I don't have access to either the NFS server or the host running the program, so mainly all I can access is some strace and SQLite tracing output. Thanks for any suggestions, Arun ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------