While testing Undark with my test DB the other night, I noticed it wasn't picking up any of the deleted rows, despite them existing in the DB still. On inspection with the hex-editor I found that the SQLite3 CLI tool has been zero-byte'ing the length and (possibly) Row-ID bytes of the header of the btree cell format record, as opposed to what's happening on the iOS edition where these two items are still intact.
A quick conversation on the SQLite IRC channel bought up the idea that maybe iOS is doing things slightly differently to assist in data-recovery (NSA?). Anyone know what the *default* method should be ( I'm assuming the zero-byteing is the correct method, as it genuinely marks the payload in a way that it cannot be casually recovered by normal methods that I'm using ). For me to recover the data deleted in this manner I'm going to have to add a heuristics algorithm. Paul. -- Computer Repairs for Charters towers - http://ctpc.biz A.B.N. 19 500 721 806 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
