Miles Waller wrote at 2008-12-4 19:42 +0000:
>fstest - no problems
>checkbtrees - no problems
>fsrefs - returns errors about invalid objects (and reports all objects
>as last updated: 5076-10-09 17:19:26.809896!), and finally fails with a
>Traceback (most recent call last):
> File "/usr/local/Zope-2.9.8/bin/fsrefs.py", line 157, in ?
> File "/usr/local/Zope-2.9.8/bin/fsrefs.py", line 130, in main
> refs = get_refs(data)
> File "/usr/local/Zope-2.9.8/lib/python/ZODB/serialize.py", line 687,
> data = oid_klass_loaders[reference_type](*args)
This indicates that "fsrefs" does not understand the data.
There are several possible causes:
* "fsrefs" does not have the correct version
* "fsrefs" has a bug
* your storage is damaged.
As you have reported that the storage content could be successfully
exported, a damage is not that likely (the export should have the
same problem in this case).
>I think I can see some corruption in the oids of the referenced objects
>as they show as:
>etc... - i wasn't expecting to see [EMAIL PROTECTED] and friends.
This does not indicate any corruption: the oids are treated as
8 byte binary strings. If a byte has a printable representation,
this one is used on printing, otherwise its hex representation.
>For example, fsrefs reports not being able to find
>'\x00\x00\x00\x00\x00#\xd4"'. However, I can load the database at the
>zopectl prompt and load objects, and get ob._p_oid to report
Looks like an "fsrefs" bug.
If you can load an object from the storage, "fsrefs" should not report
it as missing.
>I also wondered if the first few bytes of the database could have been
This is unlikely.
The first bytes contain a magic number (identifying the storage format).
I think, a "FileStorage" would not open when the magic number were
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org