Thomas Clement Mogensen wrote at 2007-9-27 12:43 +0200:
>Within the last few days something very strange has happened: All
>newly created or modified objects get a _p_mtime that is clearly
>incorrect and too big for DataTime to consider it a valid timestamp.
>(ie. int(obj._p_mtime) returns a long).
>Values I get for _p_mtime on these newly altered objects are
>with only the last few decimals differing among all affected objects.
>Objects changed at the same time appear to get the same stamp.
When I see such unexplainable things, I tend to speak of alpha rays....
Computers are quite reliable -- but not completely. Every now
and then a bit is changing which should not change.
In my current life, I have seen things like this 3 times -- usually
in the form that the content of a file changed without that
any application touched it.
When you accept such a wieldy explanation, then, maybe, I can
FileStorage must ensure that all transaction ids (they are
essentially timestamps) are strictly increasing.
To this end, it maintains a "current transaction id".
When a new transaction id is needed, it tries to construct
one from the current time. But if this is smaller than
the "current transaction id", then it increments that a little
and uses it as new transaction id.
Thus, if for some reasons, once a bit changed in the
current transaction id (or in the file that maintains it
persistently), then you may no longer get away with it.
On Plone.org, someone asked today how to fix the
effects on the ZODB of an administrator changing the system time to 2008.
If he finds a solution, then your problem may be tackled the same way.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org