Applying incorrect journal files would be bad. SQLite uses a sync
cookie to do some tricks WRT keeping the cache warm. I'm somewhat
surprised that the same thing isn't used to prevent applying journal
files inappropriately.
[I don't know this, and should not be spending time verifying it just
now, but I'll star this for looking at later.]
-scott
On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke <s...@google.com> wrote:
>
>
> On Nov 6, 2009, at 10:09 AM, mrossetti wrote:
>
>> 1) Exclude individual database files. Journal files would still be
>> backed up.
>> 2) Move the database files into a new, excluded directory. Both the
>> database files and their journals would not be backed up.
>
> By 'journal' do you mean the temporary side-file that sqlite creates
> during a transaction?
>
> If so, option 1 is potentially quite dangerous. If a journal file is
> later "restored" from backup somehow, the next instance of sqlite that
> opens a transaction on the matching database will assume that a
> previous transaction died in midstream, and use the journal file to
> restore the original contents of the database. As the restoration is
> basically just a series of binary patches, if the database is out of
> sync with the journal file, the result will be a severely corrupted
> db. I have run into this before.
>
> (The same thing happens in the opposite scenario: where the db file
> gets restored from backup, but a journal file is still lying around.)
>
> The only safe thing to do is to apply the same exclusion rule to the
> journal as to the database itself.
>
> —Jens
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
