Hi SQLite devs,
In response to a recent forum post and many other posts, where SQLite
corrupt files or Index integrity was the problem at hand, I was
wondering if we could ask for an API function that would corrupt a DB
for us.
I would like to use this to test all our systems' ability to catch bad
DBs or survive them at least. I also maintain one of the SQLite DB
management tools and would like to test it and make it more apt at
detecting, handling and perhaps even solving some of the corruptions. (I
know someone here made some recovery tools already).
A simple:
int sqlite3_makecorrupt(*sqlite3_db , Int corruptionType)
I know I can write nonsense over the file, but I was hoping to be able
to cause specific common corruptions, like Invalid-Schema, Missing Index
entries, Missing pages etc. with this command. It need not be fancy,
just find the first table that can be corrupted in the DB, and mess with
it enough to fail an integrity check, but still work if possible. (Or
whatever check is appropriate to detecting that kind of corruption, if
any). Also, making it part of the connection API, it means the file I am
corrupting had to already be opened successfully and so must be a valid
SQLite DB to start with.
A returned error code might indicate whether successfully corrupted (I
might ask to corrupt by missing Index entries, and the DB might have no
usable Indices). Other returned codes might be the usual SQLITE_BUSY,
SQLITE_NOT_A_DB and the like. (This is the kind of things hard to check
if I am just messing with the file from outside a connection).
Another possibility is to produce a file-copy (perhaps via the backup
API) of the DB that gets corrupted in stead of the DB itself - this is
probably safer and lends itself better to testing environments where I
can manufacture many different corruptions from the same DB file. Maybe
add a parameter where I can suggest the new filename.
Perhaps force a new file named to clearly indicate it (to avoid
accidents and people with nefarious intents from messing with working
DBs easily) such as:
MyDB.sqlite.corrupted
(from MyDB.sqlite as the original or suggested name).
The one thing I'm not sure about, maybe you or others have thoughts on
this, is whether the corruption should be random or repeatable.
I'm thinking this must already exist somewhat in the vast SQLite
test-suite in some form.
Thanks,
Ryan
PS: It would probably be very useful too for embedded/phone type systems
to test battery-fail or unplugged-cable type corruptions - though these
are easy to simulate already, but if in the API, it could more easily be
included in test scripts.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
