Analysis and possible solution to getting unexpected SQLITE_CANTOPEN
errors from sqlite3_step
In pagerSharedLock, there is a test for the journal file
acessability immediatly followed by an attempt to open it.
If the journal file goes away between these two actions, sqlite3OsOpen
will return SQLITE_CANTOPEN which becomes an irreversable error. On the
other hand, if the journal file had just been missing according to
sqlite3OsAccess, that would have caused a SQLITE_BUSY which is
retryable.
I propose treating CANTOPEN the same as BUSY
rc = sqlite3OsAccess(pVfs,pPager->zJournal,SQLITE_ACCESS_EXISTS,&res);
if( rc==SQLITE_OK ){
if( res ){
int fout = 0;
int f = SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_JOURNAL;
assert( !pPager->tempFile );
rc = sqlite3OsOpen(pVfs, pPager->zJournal, pPager->jfd, f, &fout);
...
if(rc==SQLITE_CANTOPEN) { rc = SQLITE_BUSY; }
There's also the harmless inefficiency that sqlite3OsOpen can return a
readonly file even though it was requested to provide a read/write file.
pagerSharedLock closes it and treats this as CANTOPEN. Both of these
are conditions where the state of the file system is changing unexpectededly,
but it seems like the right thing to go with what is true rather than what
was predicted by sqlite3OsAccess.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
