On 3/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> > Is there something that the SQLite core can do better?
>
> Perhaps exclusive locks on journal files would help avoid this problem.
> Or are the -journal and etilqs_* files supposed to be sharable by other
> sqlite processes?
>
They are, at least on unix. On unix, both files are opened with
the O_EXCL flag. How do I do the same thing for windows?
The code does that already. You just pass 0 on the share parameter and
no one can open (or delete) the file until closed. The only difference
to unix is the fact you can't delete a file while open (unless if you
pass the FILE_SHARE_DELETE, which isn't supported by Win9x).
I don't see a problem there. The problem seems to be the journal file
is opened by other programs BEFORE sqlite tries to open it, meaning
sqlite fails to open it in exclusive mode.
This case can also happen on Unix, I think. It's just the fact that
there are no (few?) programs opening all files and leaving them open
for long time that makes it less visible (In my opinion, the windows
search program is certainly leaking file handles and maybe that's what
also happens with some anti-virus).
I don't think nothing can be done about that, after rulling out
special fixes, like using special security features of the OS to make
the file only accessible to sqlite (which would involve, on install
step, the creation of a security context only sqlite could use).
What could be done is having a special error for this situation, so
the user application could be explicit with what is happening.
Regards,
~Nuno Lucas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
