I'm the author of that little patch. That looks pretty much exactly
how I did it. Modulo some messing around to handle only copying the
damaged transactions (we're dealling w/ multi-gig Data.fs files)
Can you give me more information how you determined what objects didn't
Ross Reedstrom, Ph.D. reeds...@rice.edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
The Connexions Project http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
On Tue, Nov 10, 2009 at 04:04:14PM +0100, Hanno Schulz wrote:
> we have a ZODB with a future timestamp, somewhere around 2030, after a mistake
> while setting the system time. After setting back system time the zope
> modification time of all new objects stay at the latest time.
> System: Zope 2.9.7 (ZODB 3.6.2?)/Plone 2.5x
> I reproduced this problem on a local server, to figure out how to fix it.
> While searching the net, i found this discussions
> Following this "instructions" i copied the data.fs with the patched version of
> copyTransactionsFrom with a little script like this:
> old_fs = FileStorage('var/filestorage/Data.fs', read_only=True)
> iter = old_fs.iterator()
> new_fs = FileStorage('var/filestorage/newfs.fs', create=True)
> new_fs.copyTransactionsFrom(iter,1, 1)
> And at first it seems to work, but only for objects that haven't changed
> the wrong sytemdate time.
> This error happens while modifing content in plone and zope
> and this while adding content in plone and zope
> Maybe i've done something wrong while creating the new data.fs. Or there is
> another solution to fix this problem.
> I hope you can give me hint/tip/instruction or anything else to solve it.
> Hanno Schulz
> For more information about ZODB, see the ZODB Wiki:
> ZODB-Dev mailing list - ZODB-Dev@zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org