[Felix Ulrich-Oltean]
> ...
> I think I've found the culprits - there are 4 records which give errors like 
> this:
> portal.portal_catalog.uncatalog_object('/sites/cw/data/urbanr')
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/usr/local/zope/lib/python/Products/ZCatalog/ZCatalog.py", line 558, 
> in uncatalog_object
>    self._catalog.uncatalogObject(uid)
>  File "/usr/local/zope/lib/python/Products/ZCatalog/Catalog.py", line 411, in 
> uncatalogObject
>    x.unindex_object(rid)
> File 
> "/usr/local/zope/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py", 
> line 138, in unindex_object
>    self._index[comp][level].remove(docid)
>  File "/usr/local/zope/lib/python/ZODB/Connection.py", line 597, in setstate
>    p, serial = self._storage.load(oid, self._version)
>  File "/usr/local/zope/lib/python/ZODB/FileStorage.py", line 689, in load
>    return self._load(oid, version, self._index, self._file)
>  File "/usr/local/zope/lib/python/ZODB/FileStorage.py", line 665, in _load
>    raise CorruptedDataError, h
> ZODB.FileStorage.CorruptedDataError:

and later:

> Just to follow up on the original problem, in case someone else has
> similar troubles.  It turned out that the physical disk was broken - I
> couldn't even copy the files at the os level.

Thank you for the followup!  I follow reports of FileStorage
corruption keenly, and they never have a thoroughly happy ending -- as
it implies on


the only ones that have been resolved in my experience got pinned on
HW problems, or catastrophic system software bugs.  Often the original
reporter doesn't follow up, and then we never know.  In some of those
cases, I heard later that "the problem went away" after they moved to
a different machine.  That's consistent with flaky HW, but not
conclusive.  I appreciate hearing how these turn out -- thank you.

"the ZODB guy"
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to