Packing date screwed up
I can't pack my database because at some point, with the machine time set at 2008 (don't ask) it was packed. How can I force this, or change the database date. I tried using the fsrecover, which tells me the dates are out of sequence, but doesn't do anything about it. I found a similar problem in the list archives, but no answer to it.
Error Type: FileStorageError Error Value: The database has already been packed to a later time or no changes have been made since the last pack
(Zope 2.6.0 (binary release, python 2.1, win32-x86), python 2.1.3, win32) running on WIN98 (please don't laugh). Thanks! ============================================ fishAbility: Cliff Quinn and Sam Quinn Victoria, BC, Canada (250) 727-7879 http://www.fishAbility.biz/
Cliff Quinn wrote at 2002-12-27 15:34 -0800:
I can't pack my database because at some point, with the machine time set at 2008 (don't ask) it was packed. How can I force this, or change the database date. I tried using the fsrecover, which tells me the dates are out of sequence, but doesn't do anything about it. I found a similar problem in the list archives, but no answer to it.
Error Type: FileStorageError Error Value: The database has already been packed to a later time or no changes have been made since the last pack
(Zope 2.6.0 (binary release, python 2.1, win32-x86), python 2.1.3, win32) running on WIN98 (please don't laugh). Your problem is probably bigger than you expect:
You probably also have transactions in the future. When you can, I would see whether the latest backup can be used written when the time was still normal. When this is not possible, I would use "tranalyzer" (maybe slightly differently spelled) to analyse the "Data.fs" and see how much staff comes with an wicked date and how much I would lose when I would cut the file to a safe limit. After that, I would search (using Zope's "Find" with a copy of the old "Data.fs") for the objects changed in the future and more the changes back (when they were not too many). If all were unfeasible, I would look at the source of "ZODB.fsrecover". It copies a "Data.fs" and repairs corrupt pieces. Certainly, it could be modified to salvage strange transaction times. Dieter
On Saturday 28 December 2002 7:21 pm, Dieter Maurer wrote:
Your problem is probably bigger than you expect:
You probably also have transactions in the future.
Have many other people been affected by this? ZODB could be changed to validate the system clock by comparing it to the time of the last transaction. If the difference is longer than some threshold (4 weeks feels about right) them it would conclude that it is more likely that the system clock is wrong, and refuse to issue any new timestamps at the current time without external confirmation. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
participants (3)
-
Cliff Quinn -
Dieter Maurer -
Toby Dickenson