On Wed, 23 Jun 2004 16:04:46 -0400, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > > > Michael Robinette wrote: > > Hi all, > > > > I'm investigating using sqlite(2.8.14) in a project, so I wrote some > > tests to see if I could corrupt a database. > > > > The test is this: > > > > delete db file > > sqlite_open db file > > create table > > for( ii = 0; ii < 1000; ++ii ) > > insert row > > close db > > > > if I kill the app in the loop, then run the test again, I end up with > > a corrupt database. It looks like this is because the db file is > > deleted, but the journal file is still present and gets applied to a > > now non-existent db, which results in garbage. > > > > I realize this is a somewhat contrived case, but it doesn't seem right. > > > > Is the journal the only temp file i have to worry about in a case like this? > > > > Yes, the journal file is the only file you need to worry about. > > See http://www.sqlite.org/lockingv3.html, section 6.0: "How To Corrupt > Your Database Files". Most of that document is specific to SQLite 3.0.0, > but section 6.0 applies just as well to SQLite 2.8.14. > > You present a new and novel approach to corrupting the database, which > is to combine a database file with a journal from a different database > into the same directory. We'll be thinking about what to prevent this > attack in the 6 days that remain before we freeze the 3.0.0 database > format. >
Cheers. My next test was (is still) going to be restoring from a backup database where I would have run into bullet point number 2, but I think I'm now prepared to be sufficiently defensive against these cases. (sorry about the duplicate posts, i thought the first one bounced) - michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
