If the same database file is alternately written by SQLite version 3.7.0
and version 3.6.23.1 (or earlier), database corruption can occur. The
failure scenario is this:
1. The database is created and initially populated using version 3.7.0.
2. Version 3.6.23.1 adds content, causing the size of the database to increase.
3. Version 3.7.0 updates the database without increasing its size
The corrupt is that the in-header-size field at offset 28 into
the header ends up being set incorrectly. This field was always zero for
SQLite versions 3.6.23.1 and earlier; it was introduced for the first time
in version 3.7.0. Version 3.7.0 knows to only use the in-header-size if
the change-counter at offset 24 matches the change-counter-copy at
offset 92. And so
normally, 3.6.23.1 and 3.7.0 can interact without problems. Step 2 in the
failure scenario above causes the in-header-size field to be set incorrectly
(because 3.6.23.1 changes the size of the database but does not update the
in-header-size field). The database is still valid after step 2, though,
since the change-counter-copy at offset 92 no longer matches
the change-counter at offset
28. However, step 3 updates both the change-counter and
change-counter-copy
without correcting the in-header-size, resulting in database corruption.
<hr><i>dan added on 2010-08-04 11:39:07:</i><br>
Fixed by commit [65b8636ac6].
|