SVN seems to be a standard shell extension which doesn't use low level drivers. It looks like it gets notification from Explorer and examines files that change. You see the same kinds of things happening when you try to delete media files in Windows when the shell's trying to examine the contents of the media file. The delete will fail for instance with "another process has the file open" errors. The thing is, I wouldn't expect SVN to get a notification unless Explorer happened to be opened to the folder that SQLite tries to use for temp files. What's the chance you're seeing the interaction between SVN and SQlite because you have this temp folder open?
Do you get the same results if you don't have an explorer window open to the temp folder? Maybe you don't have the same version I'm looking at but, the SVN source from June 2, 2006 doesn't seem to include a low level driver (or I'm missing it). I know what kind of driver you mean though, a file system shim. I've written them before. I think it's unlikely a real file system shim would cause this problem. You'd just see delayed opens of the file, not outright errors. One solution might be to create a temporary folder in the temp directory then create you temp file in this new folder. If you do that, and my theory is correct, you might not be able to delete the folder but, you should always be able to delete the file under it. I'd call this an SVN bug. They should probably not scan into the windows temp folders. It looks like it scans any folder and subfolders when it's notified of changes to the file system. I just made a quick scan of the source so, I could be wrong. C Sunday, June 4, 2006, 7:24:41 PM, you wrote: JS> The fix is very simple - uninstall the SVN software which causes the JS> problem. I would imagine that Sqlite is not the only piece of software JS> which expects to have exclusive access to its journals. JS> Sqlite can be changed for Windows so that it can live with other JS> processes messing with its journal, and probably should be since there JS> will always be anti-virus and similar activity on Windows. My guess is JS> that allowing read sharing on the journal on Windows would be sufficient JS> and not create parasitic problems. JS> JS JS> Costas Stergiou wrote: >> Can someone propose a reasonable workaround until this issue is fixed? >> Is "synchronous=off" really a solution? Or there is a failure 'behind' the >> scenes' that is just overlooked? >> >> Not really knowing how difficult it is to overcome this issue (and just >> trying to add an 'objective' opinion), I could just say that it is >> reasonable to expect consistency from a db engine, no matter what the >> underlying deficiencies. >> I cannot think of oracle or mysql claiming that due to a Windows buggy >> implementation, the database may fail occasionally and unexpectedly! >> >> I will need to admit thought that the limit is a bit vague here... >> Costas >> >> >> >>>-----Original Message----- >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>Sent: Δευτέρα, 5 Ιουνίου 2006 12:27 πμ >>>To: sqlite-users@sqlite.org >>>Subject: Re: [sqlite] reasonable assumptions >>> >>>Dave Dyer <[EMAIL PROTECTED]> wrote: >>> >>>>>I think this is a very reasonable assumption. >>>> >>>>It's a lot easier to drive if you assume you're the only >>>>car on the road. >>>> >>> >>>I think a more apt analogy is that it is easier to >>>drive when the stearing wheel is not jerked out of >>>your hand at random intervals. >>> >>>-- >>>D. Richard Hipp <[EMAIL PROTECTED]> >> >> >> >> -- Best regards, Teg mailto:[EMAIL PROTECTED]
