On Sat, Oct 12, 2013 at 9:24 PM, Paul L Daniels <pldani...@pldaniels.com>wrote:
> > 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. > > The iPhone is using the default method, which is to leave the bytes intact and simply mark the deleted region of the page as available for reuse by a subsequent INSERT. That is the default method because it is faster. Zeroing out the deleted fields, while quick, does take measurable time. We added the SQLITE_SECURE_DELETE compile-time option and the "PRAGMA secure_delete=ON" command for Firefox. http://www.sqlite.org/pragma.html#pragma_secure_delete -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
