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

[Tim Peters]

[Tim Peters]
>> ... 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).

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

That would go beyond the scope of suppressing fsrefs complaints (fsrefs
doesn't look at-- and so doesn't complain about --non-current revisions).
Fine by me either way, although people generally just don't notice
corruption in non-current revisions since nothing normally tries to touch
them, and they eventually go away "on their own" (when pack doesn't copy
them over).

> Im not sure what your recovery tool would do

Since you have time to think about it, let's henceforth call it *your*
recovery tool <wink>.

> if the current revision is corrupt except, as you say, delete everything.

It would have to throw away the current revision of that object;
"everything" seems too strong a phrasing.

> 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.

Doing such patching would be the primary action of the tool.  For example,
ZODB 3.3 has a PersistentBroken class, and in the otherwise-good object a
reference to an instance of that (or something like it) would replace the
ref to the damaged object.  fsrefs would shut up then, although any attempt
to follow that reference would yield a useless (albeit real) object.

> 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.

Let me know when it's ready <wink>.  I'll note that there's nothing that can
be automated that's necessarily semantically safe, not even an undo.  A
database creator may be able to know what's semantically safe in specific
cases, though.