Gilles Lenfant wrote at 2003-10-22 15:00 +0200:
If you are unlucky, your ZODB is corrupted and it might be difficult to get rid of these errors again.
Seems that it's the case... I made a new Zope 2.6.2 instance, with the same products, then copied the Data.fs to that new instance. That new instance refuses to start : raising the same exception, then stopping (panic mode).
Do you think that starting a new Zope 2.6.2 instance with the same products and a virgin Data.fs then exporting/importing all folders at root as zexps would fix this ?
When you are able to export (you probably are) you will come a good step forward. However, you will nevertheless have some inconsistency. The Zope 2.6.1 Version bug has been that only a single object was moved from the Version to the non-Version state when you committed the Version. All other objects in the Version remained (partly) in the Version (and continued to be locked). When you export, you will get the (new) object moved from the Version but all other objects modified in the Version will be exported in their unmodified state. I do not expect that this will be a big problem. However, depending on what you changed in the version, this may be wrong. Whether it is a problem can already be seen in your current Zope setup. The inconsistency already exists there (with the additional locks for objects modified in the Version).
$ python utilities/ZODBTools/fstest.py -v var/Data.fs ... var/Data.fs truncated possibly because of damaged records at 1117825536
But I dunno how to fix this...
This problem will be fixed by "fsrecover". But, do not use the 2.6.1 version (it is broken). Use the 2.6.2 version. Dieter