[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