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