[Zope-dev] Packing (still) hosed in 2.6.2?

[Anthony Baxter]

>>> "Jeremy Hylton" wrote
> I don't recall that any of the pack bugs that we fixed caused this sort of
> error.  My first guess would be that the file is a bit damaged, perhaps in a
> way that the old pack did not check.
> Can you run fsdump.py and see if that output sheds any light.  It will give
> you a detailed text summary of all the transactions and data records.  You
> could use the dump to figure out if, for example, the two numbers in the
> error message are indeed transaction header locations.

Ok. The original error, reformatted for clarity:

ZODB.fspack.CorruptedError: 
    /app/zope/dev_csr_server/recover/Data.fs:9200838:
        data record does not point to transaction header: 
            17391715 != 9200760

Here's the 3 transactions (one before, dead one, one after). There's
definately a screwed transaction there.

============================================================
offset: 9198385
end pos: 9200752
transaction id: 033bb0f41f05f3aa
trec len: 2367
status: ' '
user: ' jasonb'
description: '/admin_tools/accounts/update_account/manage_edit'
len(extra): 0
------------------------------------------------------------
offset: 9198463
oid: 00000000000206bb
revid: 033bb0f41f05f3aa
previous record offset: 9193826
transaction offset: 9198385
len(data): 2247
redundant trec len: 2367
============================================================
offset: 9200760
end pos: 9202513
transaction id: 033bb0f4b80ad42a
trec len: 1753
status: 'u'
user: ' jasonb'
description: '/admin_tools/accounts/update_account/manage_edit'
len(extra): 0
------------------------------------------------------------
offset: 9200838
oid: 00000000000206bb
revid: 033bb0f4b80ad42a
previous record offset: 17389418   # XXXX woopsie
transaction offset: 17391715       # XXXX woopsie
len(data): 1633
redundant trec len: 1753
============================================================
offset: 9202521
end pos: 9204883
transaction id: 033bb0f7be87736e
trec len: 2362
status: ' '
user: ' jasonb'
description: '/admin_tools/accounts/update_account/manage_edit'
len(extra): 0
------------------------------------------------------------
offset: 9202599
oid: 00000000000206bb
revid: 033bb0f7be87736e
previous record offset: 9198463
transaction offset: 9202521
len(data): 2242
redundant trec len: 2362
============================================================


So, fixing this. fsrecover.py doesn't do the right thing, unfortunately.
It just leaves the broken record alone. I'm not sure if making fsrecover
handle this class of error is useful...

It should be simply a matter of walking through the transactions, and
patching the one that's busted. Or alternately, simply skipping it.

I'll look into fixing this now. More in a bit.

Anthony