[ZODB-Dev] Re: [Zope] HELP - POSKeyError 000000000001efcd - Data.fs corruption

Toby Dickenson tdickenson@geminidataloggers.com
Thu, 20 Mar 2003 14:03:02 +0000


On Thursday 20 March 2003 1:38 pm, BZ wrote:
> [I posted to zodb-dev as I was told they were the GURUs and could help
> since this is in the ZODB).
>
> What I have tried:
> 1) Using fsrecover.py (with and without -p and before and after packing)
>
> This has removed data but along with it a lot of data that I need. If you
> don't use the -p it removes nothing and I am stuck with the POSKeyError

fsrecover works on the FileStorage record structure. It wont do anything to 
mitigate POSKeyErrors, but you shouldnt see errors like this one after 
running it. Please shout if this is not the case for you.
> > You also reported:
> >>> 119583146L object serialno 0x034aab9e4b7e624c does not matchtransaction
> >>> id 0x034ac5e367948900

> 2) Exporting the folder I think is corrupt (/Members/) and importing it
> into a new CMF.
>
> It imports, but the POSKeyError comes with (in a new location)

Dont think that this means it is creating more corruption. Things stop when it 
hits the first POSKeyError, so you *might* just have two missing objects and 
they are being hit in a different order.

Do you get most of the /Members content working with this process?  If so, 
your problem is not as hard as it could be. You just need to find the objects 
that have dangling references, then either reconstruct the referenced object, 
or delete the object that contains the dangling reference.

There is an fsrefs.py script that might help. (Ive never used it, but it looks 
good.)

> Any new direction would be appreciated. The problem with hosing the darn
> /Members/ folder is that it has Members stuff in it.

When this immediate problem is resolved you may want to look at 
DirectoryStorage. I developed it after suffering this kind of debuggability 
problems in other storages.

-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson