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/", line 157, in ?
>    main(path)
>  File "/usr/local/Zope-2.9.8/bin/", line 130, in main
>    refs = get_refs(data)
>  File "/usr/local/Zope-2.9.8/lib/python/ZODB/", line 687, 
>in get_refs
>    data = oid_klass_loaders[reference_type](*args)
>KeyError: 'n'

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 
>cut off

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  -

Reply via email to