On Wed, 26 Jul 2006 15:23:04 +0100 (BST), you wrote: >Looking at this reminded me. What is the point of deleting the rollback >log? Why not just truncate it when committing a transaction, and deleting >it only when closing the database?
My guess: Because sqlite has to deal with so many platforms, it shouldn't make as few assumptions as possible about the 'correctness' of any filesystem. Deleting the journal file would have a bigger chance to actually cause a directory update on harddisk than a mere reset of filesize. Mind powerfailures and system panics. To be sure, in your construction a simple truncate wouldn't be enough, additionaly the contents of the journal should be invalidated in some way, with a guaranteed flush to the filesystem. As the journal is our last resort for database consistency (thus the ACID nature of sqlite), it is better to be safe than sorry. >The benefits could be: >- Improved performance: > - No delete of the rollback log to cause synchronous IO on the > directory. There is the consistency culprit. > - Only need to create the rollback log when it doesn't exist. Else, > just the existing empty one. > >- Would play better with Virus scanners on Windows. No deleting of the > rollback log would cause no file locked errors until we're closing the > database. IMHO we'd better make the virusscanners behave. >So long as the rollback code handled the case of the rollback journal not >being present, this should be backward compatible with existing versions. True. >Christian -- ( Kees Nuyt ) c[_]
