Wow, the wiki article on Data.fs, corruption, backup, etc. What a gem,... never saw that before. Just wanted to let you know, one question answered helps others. Much Appreciated, -Jon Cyr cyrj@cyr.info RE: http://zope.org/Wikis/ZODB/FileStorageBackup . Tim Peters wrote:
[shan sverige]
When I try to pack I get:
Error Value: /usr/local/Zope-2.7.0/var/Data.fs:31906881:time-stamp reduction: 03537a82059cf1cc <= 0355bcc95b5ace33
Ouch. Looks like the system clock on your machine got set backwards by about 3 months at some point:
from ZODB.utils import * print TimeStamp.TimeStamp(p64(0x03537a82059cf1cc))
2004-03-02 17:38:01.315562
print TimeStamp.TimeStamp(p64(0x0355bcc95b5ace33))
2004-06-12 12:57:21.411260
Then you got bit by this:
http://zope.org/Collectors/Zope/1327
While no distinct ZODB release was made to correspond with Zope 2.7.2, that bug should be fixed in Zope 2.7.2. It's still a panic-level problem if the clock is seen to go backwards by that much, but at least a panic message will get logged about it now, and FileStorage will force transaction ids to be monotonically increasing anyway now.
In any case, packing isn't an error recovery procedure. Run the diagnostic scripts explained here, and start making backups (also explained here):
http://zope.org/Wikis/ZODB/FileStorageBackup
After running fsrecover.py the resulting Data.fs can't be mounted. I now get:
ZODB.POSException.ConflictError: database conflict error
Sorry, but I bet you have multiple problems in your database now, and probably stemming from whatever went wrong with your system that caused your clock to go insane. This could be difficult to recover from. Running fstest and fsrefs (explained on the page linked to above) will help determine the extent of the damage.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )