On Tuesday 21 January 2003 7:58 am, Paul Winkler wrote:
The really fun thing about POSKeyErrors in particular is that I know of no way to find out what zope id the broken oid once belonged to. Is there any way?
It shouldnt be hard to change fsrefs to dump the oid reference chain that leads to the dangling reference. DirectoryStorage 1.0 will do that if it finds a dangling reference during packing - for 1.1 I plan to move that feature into checkds where it belongs. However an oid reference chain wont tell you the application-level id of the object, but you can deduce that by looking at pickles.
I tried mounting a copy of the backup with another Zope instance, exporting the recent stuff, and importing it into the zope running the "repaired" Data.fs, but every time I tried to do that I got POSKeyErrors. (!)
Yes. The export procedure silently ignores any POSKeyErrors. Importing that export will create a nice clean dangling reference. Thats a feature, not a bug.
The repaired Data.fs passes fstest.py with no errors, so I think somehow the exports from the backup bring the POSKeyErrors with them. It's like a virus!!!
You imported some dangling references. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson