On Sep 26, 2017, at 8:22 AM, Jens Alfke <j...@mooseyard.com> wrote:
> The basic error code is SQLITE_IOERR, which just means "Some kind of disk I/O
> error occurred” according to the comment. Which is true in this case; an I/O
> operation returned an error.
But the *disk* didn't - the *operating system* did, so if SQLITE_IOERR really
means "Some kind of disk I/O error occurred", it's *not* the right error to
return for a *permission* error.
And, on UN*X, a write() call can return ENOSPC; a write() is an I/O operation,
and "returns -1 with errno set to ENOSPC" is an error, but that presumably gets
reported as SQLITE_FULL, not as SQLITE_IOERR.
Sadly, the name chosen for that error code
1) suggests an "I/O error" in the sense of "a device reported an error
trying to read or write it"
and
2) is probably part of the API and thus unchangeable.
However, if SQLITE_IOERR is returned for *anything* other than, on UN*X, an EIO
errno:
1) The documentation should *really really really really really* avoid
calling it an "I/O error", as "I/O error" has a connotation of "the device
reported an error" (which is what EIO signifies) rather than "an I/O operation
got some sort of error, not necessarily an error from the device from which we
were trying to read data or to which we were trying to write data".
2) The documentation should tell people *always* to use
sqlite3_system_errno() after an SQLITE_IOERR and report the error based on
*that*, not just by reporting an "I/O error". Yes, that means writing
platform-dependent code; if you want to allow platform-independent code to be
written atop SQLite, stuff the platform dependency inside SQLite, by providing
some API to get errors such as, for example, "permission denied" or "disk quota
exceeded" or "an actual disk I/O error occurred" rather than "write() got some
error other than ENOSPC". (Yes, you *can* get "permission denied", e.g. in an
NFSv2/NFSv3 write to a file to which you had write permission when you opened
it but to which you no longer have write permission, and, yes, if, for example,
you're in the remote file system group at Apple, with a home directory on an
NFS server, you can have an SQLite database being accessed over NFS.)
> If you want more detailed info, use extended error codes by calling
> sqlite3_extended_result_codes() or sqlite3_extended_errcode(). Then you’ll
> get a more specific error; in your situation probably SQLITE_IOERR_ACCESS.
Perhaps, in that particular code path, the permission problem would show up in
an xAccess method call, so that this would happen to be able to give you a
better error.
However, what matters isn't "what operation got the error?", it's "what
non-file-system-full error did you get?", and the extended error code won't
help for errors other than ENOSPC and EIO returned by write().
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
