[EMAIL PROTECTED] schreef:
See http://www.sqlite.org/cvstrac/chngview?cn=3200 for the fix.
In the changes i don't see calls to 'GetLastError()' as MS suggests.. Error logging might help tracing the error. Maybe a sqlite error log is a usefull feature request..
Another hint from the DeleteFile api documentation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/deletefile.asp reads "If you request delete permission at the time you create a file, you can delete or rename the file with that handle, but not with any other handle. For more information, see File Security and Access Rights <http://msdn.microsoft.com/library/en-us/fileio/fs/file_security_and_access_rights.asp>." However i am unable to find how to delete a file based on this handle, all msdn docs say you should close the/all handle(s) prior to deleting.. Another suggestion done by MSDN (and known workaround) is renaming the file prior to deleting. Renaming will succeed even is the file is open for reading, and at least a new journal can be created...However, if it will work it will put additional overhead on each transaction.
The pause and retries in the patch seem very arbitrary, they may not work correctly if the journal file is larger (several Mb or so), but it may be good for tracing the issue.. Since putting synchronous to OFF seems to help, it suggest a timing error. You could try to close the handle, delete the file right after, and only then flush buffers to disk, so no flushing after file handle was closed, since this few hudred ms allows other applications to quickly open the file.
However, to be honest, personally i do not favour creating workarounds for things that are supposed to work but are affected by other software. It this case, i think it is reasonable to say the cause is outside sqlite, namely a virrusscanner or tortoiseSVN. Any self-respecting virus scanner will have kernel hooks to monitor I/O, acting transparently to applications (= no unexpected 'locking' issues) which leaves tortoise.
If tortoiseSVN uses ReadDirectoryChangesA/W() to monitor the disk, opens files for scanning for changes, and thereby locks sqlite, i am feeling to say it is a bug in tortoise, not in SQLite.. Maybe configuring tortoise to skip journal files would already fix it, if such feature is not available they could easily implement it (just skip all files that SVN is supposed to ignore anyhow, unlikely one would want to have journal files in the SVN repository).. I've tried using such drive monitoring technique in the past, see http://www.howtodothings.com/computers/a841-how-to-create-a-pre-caching-system.html and encountered several issues with applications that looks a lot like this very issue... If this is the case, there would be no 'uniform' fix, since you will not know what the remote application is doing, only hoping it will release it's handle soon.
Apologies for not having a straight forward fix.. The changes made to win_os.c do not seem a real solution but also won't do any harm probably... It seems NT allows some more control to file and directory access than win9x, but splitting the win_os layer may not be desired.. As far as i see the cause is outside sqlite, so i think it probably should be fixed outside sqlite.
kind regards, Rene
