Hi,
we found a rather serious bug in the retry logic in Windows VFS in
SQLite 3.7.9. The function winAccess has roughly the following
structure:
while( !(rc = GetFileAttributesExW((WCHAR*)zConverted,
GetFileExInfoStandard,
&sAttrData)) && retryIoerr(&cnt) ){}
if( rc ){
...
}else{
logIoerr(cnt);
if( GetLastError()!=ERROR_FILE_NOT_FOUND ){
winLogError(SQLITE_IOERR_ACCESS, "winAccess", zFilename);
free(zConverted);
return SQLITE_IOERR_ACCESS;
}else{
attr = INVALID_FILE_ATTRIBUTES;
}
}
Note the logIoerr line. It internally calls sqlite3_log, which in turn
can change the "last error" that is checked on the next line.
This results in this totally useless log:
11/10/2011 17:23:46 10 delayed 25ms for lock/sharing conflict
11/10/2011 17:23:46 3338 os_win.c:34346: (0) winAccess(C:\Users\Filip
Navara\AppData\Roaming\eM Client\event_data.dat-journal) - The
operation completed successfully.
11/10/2011 17:23:46 3338 statement aborts at 5: [ATTACH DATABASE
'C:\Users\Filip Navara\AppData\Roaming\eM Client\event_data.dat' AS
'event_data';] disk I/O error
Also, the library actually fails to behave correctly since even if
ERROR_FILE_NOT_FOUND is returned, it is overwritten by the the
sqlite3_log call and the function returns an error.
Solution is to save the value returned by GetLastError() before
calling logIoerr.
Also note that the underlying error is not caused by an antivirus, it
is caused by Windows Search. It can also be easily workarounded in a
better way by renaming a file before deleting it in winClose and/or
winDelete. That will ensure that even if the file remains in the
"delete pending" state (ie. because other application has a handle on
the file) it will not cause further CreateFile calls on the same name
to fail.
Best regards,
Filip Navara
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
