[ZODB-Dev] Preliminary notes from fixing a bad data.fs

[Toby Dickenson]

On Monday 10 January 2005 16:21, Tim Peters wrote:

> Definitely not the default.  I think I'd be happiest with a new, distinct
> recovery tool, acting in relation to fsrefs as fsrecover stands to fstest:
> shut up fsrefs complaints even if it has to throw away the entire database
> to do so (which latter may in fact be necessary).

You can throw away corrupt non-current revisions of objects. All you lose is 
the ability to undo.

Im not sure what your recovery tool would do if the current revision is 
corrupt except, as you say, delete everything. The first bad object B has to 
be referenced by some good object A, You cant remove B without leaving a 
dangling reference to B in A, and you dont have any automated way to patch A 
to remove the reference to B.

Or maybe the current revision of B is corrupt but an older revision is not: 
you could undo the transaction in which the bad revision was written. I have 
used that trick manually, and it might be interesting to automate.

-- 
Toby Dickenson