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