>>> "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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )