|Title:||Database corruption by alternating writes from 3.7.0 and 3.6.23|
|Last Modified:||2010-08-04 11:40:07|
|Version Found In:||3.7.0|
If the same database file is alternately written by SQLite version 3.7.0
and version 188.8.131.52 (or earlier), database corruption can occur. The
failure scenario is this:
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 184.108.40.206 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, 220.127.116.11 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 18.104.22.168 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.
dan added on 2010-08-04 11:39:07: