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 >something like: >8078347503.108635 >with only the last few decimals differing among all affected objects. >Objects changed at the same time appear to get the same stamp.
Looks interesting.... 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 give one: 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. -- Dieter _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
