Thanks everyone,

We actually found a solution the day after my post. inspired by on among others.
The quick fix is in three parts:
1. An offline script for simply copying every transactions to a new FileStorage, effectively making a copy of the zodb, as described in the above. This gets rid of the bad timstamps on trasactions, but does not change any actual objects. 2. An External Method for "touching" all objects with bad timestamps. This just calls bobobase_modifacation_time(), catches DateTime.TimeError and sets _p_changed. 3. We're all happy that we don't need to tell the client to repeat 2 days x 30+ editors worth of zodb changes.

If any of you see usefullness in a polished script for this (and maybe comparable scenarios) I'll be glad to help.

Thanks again!

After thought:
These kinds of unexplained phenomena are so scary! Are we all confident this couldn't have been caused by an obscure bug?

Den 28/09/2007 kl. 18.09 skrev Christian Theune:

Am Freitag, den 28.09.2007, 07:38 -0700 schrieb Leonardo Rochael:
The solution was to chop transactions off the Data.fs till it started
behaving again. To do that, truncate the last few bytes off of your Data.fs (say, 10 bytes) and restart, Zope will discard the partial transaction at the end and start successfully. If your system is still not behaving, rinse and repeat. You WILL lose the data in these last transactions you truncate.

IIRC fsrecovery should help to do that without manual intervention.


gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle/saale - germany - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to