> 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?
Well, this is partly true. There is a background process (TSVNCache.exe) that is launched automatically when explorer starts up. If I kill the process, it will be recreated as soon as explorer starts again (but not before that). > Do you get the same results if you don't have an explorer window open > to the temp folder? You are correct in assuming that the problem is more obvious when explorer is open and 'browsed' to the folder where the sqlite transactions are made; unfortunately this is not always the case! Even if I close ALL explorer windows (and leave the TSVNCache running) I will still get this error, but in a lower frequency. But I think this is only an issue with the SVN process (probably it shouldn't behave like that). Anyway, the problem is not "how to use SQLite and SVN on the same machine", but the more generic file locking issue being discussed here. It is good that SVN can be used as a repeatable 'problem' case in order to track and resolve the real issue with SQLite. > 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. Propably I made a mistake here by explicitly saying that this is a 'low level driver'. I don't really know how this is implemented, I do know, though, that it intervenes when file activity is happening... (The filemon util will make this clear);
