I tracked the initial failure into sqlite3WinDelete, which is
used to delete journal files. There is a semi-kludge to retry
the deletion, based on the ad-hoc observation that sometimes the
delete fails because some other process has the file open.
Two observations:
(1) the retry count of 3 seems low. Retrys are rare,
If this process fails it causes a serious failure,
so we shouldn't be nervous about delaying before
throwing in the towel.
(2) the problem in my application seems to be not the number of
retries, but the call to GetFileAttributesW. I don't recall any
discussion what function this should be performing, but if
GetFileAttributesW fails with -1, no retries are attempted.
I fixed the problem (for my app) by removing the GetFileAttributesW
clause entirely.
#define MX_DELETION_ATTEMPTS 3
static int sqlite3WinDelete(const char *zFilename){
int cnt = 0;
int rc;
void *zConverted = convertUtf8Filename(zFilename);
if( zConverted==0 ){
return SQLITE_NOMEM;
}
SimulateIOError(return SQLITE_IOERR_DELETE);
if( isNT() ){
do{
rc = DeleteFileW(zConverted);
}while( rc==0
// && GetFileAttributesW(zConverted)!=0xffffffff
&& (cnt++ < MX_DELETION_ATTEMPTS)
&& (Sleep(100), 1) );
}else{
#if OS_WINCE
return SQLITE_NOMEM;
#else
do{
rc = DeleteFileA(zConverted);
}while( rc==0
// && GetFileAttributesA(zConverted)!=0xffffffff
&& (cnt++ < MX_DELETION_ATTEMPTS )
&& (Sleep(100), 1) );
#endif
}
sqliteFree(zConverted);
OSTRACE2("DELETE \"%s\"\n", zFilename);
return rc!=0 ? SQLITE_OK : SQLITE_IOERR_DELETE;
}
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
