Hi, I sometimes got this in random (?) places in a Zope 2.6.1 box Error Type: VersionLockError Error Value: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x04\\xfe'", '/stuff/versionMenus') The traceback... Traceback (innermost last): Module ZPublisher.Publish, line 102, in publish Module Zope.App.startup, line 200, in commit Module ZODB.Transaction, line 235, in commit Module ZODB.Transaction, line 349, in _commit_objects Module ZODB.Connection, line 391, in commit - __traceback_info__: (('BTrees._IOBTree', 'IOBucket'), '\x00\x00\x00\x00\x00\x00\x04\xfe', '') Module ZODB.FileStorage, line 726, in store VersionLockError: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x04\\xfe'", '/stuff/versionMenus') Tere's something I can't understand : * The "/stuff" folder has been removed for a long time * This error raises on objects with no connection with that "/stuff", even when browsing ZPT in the Zope help... Is my ZODB corrupted ? How to get rid of this ? Many thanks in advance. --Gilles
Gilles Lenfant wrote at 2003-10-21 16:26 +0200:
I sometimes got this in random (?) places in a Zope 2.6.1 box
Error Type: VersionLockError Error Value: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x04\\xfe'", '/stuff/versionMenus')
Zope 2.6.1 had a nasty bug with its Version support. If you are lucky, then you can abort the versions via "Control_Panel --> Version Management". If you are unlucky, your ZODB is corrupted and it might be difficult to get rid of these errors again. Dieter
Many thanks Dieter for your pointers... ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Gilles Lenfant" <gilles@pilotsystems.net> Cc: <zope@zope.org> Sent: Tuesday, October 21, 2003 10:57 PM Subject: Re: [Zope] VersionLockError ???
Gilles Lenfant wrote at 2003-10-21 16:26 +0200:
I sometimes got this in random (?) places in a Zope 2.6.1 box
Error Type: VersionLockError Error Value: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x04\\xfe'", '/stuff/versionMenus')
Zope 2.6.1 had a nasty bug with its Version support.
I noticed this :)
If you are lucky, then you can abort the versions via "Control_Panel --> Version Management".
Says "There are no non-empty versions." Seems I'm not lucky.
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 ? $ 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... Cheers --Gilles
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
----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Gilles Lenfant" <gilles@pilotsystems.net> Cc: <zope@zope.org> Sent: Wednesday, October 22, 2003 7:26 PM Subject: Re: [Zope] VersionLockError ???
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.
Many thanks Dieter. Gonne make the export/import in a brand new 2.6.2 instance cause the fsrecover said it fixed but running then Zope always mentions the lock problem. --Gilles
participants (2)
-
Dieter Maurer -
Gilles Lenfant