A suggestion for the journal files would be to make them private
anonymous mapped objects. That works on both Unix and Windows and any
other POSIX compatible system. Then the journals would be impervious to
outside interference.
With Unix the mapped object has a fixed size so there would need to be a
little logic to extend the size. When I have used this method on Unix I
have expanded the file exponentially by doubling the size at each
expansion to minimize expansion cycles.
A bonus of using the mapped object is that i/o is a little faster
because read and write calls and buffer shadowing are avoided.
Joe Wilson 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?
http://www.backupassist.com/BackupAssist/faq.html
"Basic support - open files locked with a shared lock or no lock are
copied and backed up after the main backup. Files with an exclusive
lock cannot be copied or backed up. Exclusively locked files are
typically SQL Server or Exchange data files."
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
