[ZCM] [ZC] 1307/ 4 Comment "fsrecover.py is broken on cvs head (or
Data.fs is really corrupted)"
Collector: Zope Bugs, Features,
and Patches ...
zope-coders-admin at zope.org
Mon May 3 14:06:15 EDT 2004
Issue #1307 Update (Comment) "fsrecover.py is broken on cvs head (or Data.fs is really corrupted)"
Status Accepted, Zope/bug medium
To followup, visit:
http://collector.zope.org/Zope/1307
==============================================================
= Comment - Entry #4 by tim_one on May 3, 2004 2:06 pm
FYI, testRecover.py tries to ensure that fsrecover isn't completely hosed -- but, AFAICT, it's almost impossible for a test in testRecover.py to fail(!). I'm adding a new test there that doesn't deliberately damage the input .fs, and that new test is generated scads of error msgs too. However, testRecover.py suppresses all the error output, so the test thinks it passed. This will take some doing to untangle.
________________________________________
= Assign - Entry #3 by tim_one on May 3, 2004 11:23 am
Status: Pending => Accepted
Supporters added: tim_one
Thanks for the report! Assigned to me.
________________________________________
= Comment - Entry #2 by slinkp on May 3, 2004 11:11 am
whoops, meant to select Database as the topic.
________________________________________
= Request - Entry #1 by slinkp on May 3, 2004 11:10 am
fsrecover.py is broken on current zope HEAD...
... either that, or brand-new filestorages created by zope
really are corrupted.
To reproduce:
- create a fresh Zope instance
- start zope
- stop zope
- run fsrecover.py on the brand new Data.fs
Result is about 900 lines like this:
0 . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 error reading txn header: invalid transaction length, 0, at 1369028
==============================================================
More information about the Zope-Collector-Monitor
mailing list