[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 http://zope.org/Wikis/ZODB/FileStorageBackup 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"