On 18/10/2012 8:45 AM, Richard Hipp wrote:
On Wed, Oct 17, 2012 at 4:11 PM, Efim Dyadkin <efim.dyad...@pdgm.com> wrote:
Hi,
I am testing loss of data in Sqlite database correlated to auto-mounter
malfunction. I am running Sqlite on Linux and my database file is located
on network disk. For a test I stop the auto-mounter right before
transaction is committed. Surprisingly commit succeeds without any error
although hot journal remains on disk. When I get auto-mounter back and open
my database again the transaction is rolled back.
Apparently Sqlite cannot remove the journal due to unmounted path but it
ignores this error because Linux classifies it as ENOENT and unixDelete
function disregards it:
if( unlink(zPath)==(-1)) && errno!=ENOENT ){
return unixLogError(SQLITE_IOERR_DELETE,
"unlink", zPath);
}
Can somebody please explain why "errno!=ENOENT" is required in here?
The purpose of unlink() is to make it so that the file does not exist.
ENOENT indicates that the file does not exist, and so the purpose of the
unlink() call has been fulfilled.
Suppose SQLite did treat ENOENT as an error. What could it do about it?
It cannot roll the transaction back because the rollback journal (and
indeed the entire database) has disappeared. I guess we could return
SQLITE_CORRUPT. Would that somehow be more useful to the application?
Is there some plausible scenario for which an active journal file gone
AWOL does *not* indicate a serious problem? To me it indicates that Bad
Things are going on that sqlite is ill-equipped to deal with, so the
best it can do is avoid causing any collateral damage by attempting to
continue normally. Especially if the filesystem went down: it's not like
any future transaction would succeed anyway...
If a less heavy-handed approach is desirable, perhaps a failed unlink()
call should trigger an fstat() or seek() on the offending file
descriptor; that might distinguish whether the file itself is
inaccessible (as in OP's case) or whether it's just unreachable at the
expected path (e.g. due to interference from an external agent).
I would still favor a fail-fast approach that returns a scary error
message, though, the same kind that would be returned if a write failed.
$0.02
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
