>>>>> "JW" == Joachim Werner <[EMAIL PROTECTED]> writes:
JW> Hi! I have a really large Data.fs file (1.3 GB) that has a JW> number of errors. When I run the fstest.py script, I get this: JW> Problem: 109963117 object serialno 0x034573c4b6a2cb6e does not JW> match transaction id 0x034573c55c8c0dbb JW> How can I fix the Data.fs file? It should be possible to scan JW> the Data.fs and create correct serialnos or transaction ids for JW> the broken entries. But how exactly would I do that? JW> I'd also like to identify the corrupt entries (i.e. find out the JW> Zope object they belong to) to be able to eliminate them. I'd start by running fsdump.py and identifying what transaction and objects are affected by this problem. fsdump will display transaction metadata (like time) and oid & class for each object. JW> My ultimate question is how these corrupt entries can exist at JW> all. The Data.fs hit the 2 GB border once. So that could be a JW> reason. But even then it would be really nice for the ZODB to JW> not write corrupt entries ... I agree that ZODB should not write the corrupt entries. It's possible, of course, that it didn't. It's certainly possible for bit-rot to strike a Data.fs, although it seems odd that the only manifestation of a disk failure would be a mismatch between object serialno and transaction id. I might be able to help more by looking at the actual Data.fs. Are you in a position to share it? (I can be discrete ;-). Jeremy _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )