[ZPatterns] Problems using fsrecover.py from 2.5.1 with 2.4.3?

[Steve Alexander]

Jean Jordaan wrote:
> Hi all
> 
> I'm attempting to diagnose a Data.fs that might be wonky. I'm
> sending a record of my attempt to the list in the hope that
> other people are better at interpreting the results than I am.
> 
> It was written by this Zope:
> 
>  $ cat ./lib/python/version.txt
>  Zope 2.4.3 (binary release, python 2.1, linux2-x86)
> 
> The fsrecover.py I'm using comes from:
> 
>  Zope 2.5.1b1 (source release, python 2.1, linux2)
> 
> I get 710849 errors like this:
> 
>  __main__.ErrorFound: invalid status, ^@, at 179898912
>  __main__.ErrorFound: invalid status, ^@, at 179898995
> 
> 2068 errors like this:
> 
>  __main__.ErrorFound: bad transaction length at 231384331
> 
> 57 errors like this:
> 
>  exceptions.SystemError: Failed to import class Trigger from module
> Products.ZPatterns.SkinScript.Components

Sounds like you don't have the PYTHONPATH set correctly.


> I can start a Zope on the "recovered" Data.fs without problems,
> and access it through a browser. It works fine, until I try
> to access certain ZClasses stored on Racks (eg. 'License'
> instances raise KeyErrors, 'Customer' instances are fine). Then
> I get KeyErrors, with this in the log:
> 
> ------
> 2002-05-01T13:14:11 ERROR(200) ZODB Couldn't load state for
> '\x00\x00\x00\x00\x00\x03O\xf8'
> Traceback (innermost last):
>   File /usr/local/zope/2-4-3/lib/python/ZODB/Connection.py, line 519, in
> setstate
>   File /usr/local/zope/2-4-3_for_diepdink/lib/python/ZODB/FileStorage.py,
> line 588, in load
>     (Object:
> /home/httpd/zope-instances/jean/creme.rel-0_9_0-branch/var/Data.fs)
>   File /usr/local/zope/2-4-3_for_diepdink/lib/python/ZODB/FileStorage.py,
> line 564, in _load
>     (Object:
> /home/httpd/zope-instances/jean/creme.rel-0_9_0-branch/var/Data.fs)
> KeyError: Oř
> ------

Sounds like you have some bad pickles in your Data.fs.
Any idea what cause the corruption in the first place?

I've recovered data from a corrupted Data.fs like this before. However, 
it's a bit of an awkward job.

Basically, you find out exactly which objects are corrupted, then remove 
references to those objects from their containers, then try to export a 
.zexp file of your data, and import it into a fresh Data.fs.

If you have Data.fs.index files around, don't lose them. They are 
probably what is allowing your Zope to start up successfully.


> For the record, during startup, Zope warns:
> 
>  WARNING: Python C API version mismatch for module DynPersist:
>    This Python has API version 1010, module DynPersist has version 1007.
> 
> We haven't been able to successfully recompile the dynpersist module,
> so we've been ignoring the warning.

I wouldn't ignore that warning. I suggest recompiling the dynpersist module.

--
Steve Alexander