Hello All, After a linux machine crash or cold restart something strange is going on with Zope (2.2.2) - all objects built on ZClass-based products like Yihaw or QSurvey are broken. Products are in Product folder, and i even can add an object and it works, but when i try to access it in a new browser window it reports ========== This object is broken because the unknown product that created it is no longer installed or is installed incorrectly. Please contact your product vendor for assistance. Note that the data associated with this product has not been lost, and will be accessible again if the product is reinstalled. ========== Well, i removed QSurvey and tried to re-install its current version - something goes wrong again: ========== Zope Error Zope has encountered an error while publishing this resource. Error Type: Could not load oid ={, pickled data in traceback info may contain clues Error Value: None ========== Is there any way to fix ZODB less radical than complete reinstall? -- Best regards, Alexander N. Chelnokov Ural Scientific Institute of Traumatology and Orthopaedics 7, Bankovsky str. Ekaterinburg 620014 Russia ICQ: 25640913
In your start script, set the STUPID_LOG_FILE environment variable to the path of a file to which you want log messages to be sent (before 'start' calls z2.py). Then review the log file. You'll probably get more clues as to what is going wrong, allowing you to fix the problem. ----- Original Message ----- From: "Alexander Chelnokov" <alex@orto.unets.ru> To: <zope@zope.org> Sent: Wednesday, November 08, 2000 12:41 PM Subject: [Zope] Is data.fs corrupted?
Hello All,
After a linux machine crash or cold restart something strange is going on with Zope (2.2.2) - all objects built on ZClass-based products like Yihaw or QSurvey are broken. Products are in Product folder, and i even can add an object and it works, but when i try to access it in a new browser window it reports ========== This object is broken because the unknown product that created it is no longer installed or is installed incorrectly. Please contact your product vendor for assistance. Note that the data associated with this product has not been lost, and will be accessible again if the product is reinstalled. ==========
Well, i removed QSurvey and tried to re-install its current version - something goes wrong again:
========== Zope Error Zope has encountered an error while publishing this resource.
Error Type: Could not load oid ={, pickled data in traceback info may contain clues Error Value: None ==========
Is there any way to fix ZODB less radical than complete reinstall?
-- Best regards, Alexander N. Chelnokov Ural Scientific Institute of Traumatology and Orthopaedics 7, Bankovsky str. Ekaterinburg 620014 Russia ICQ: 25640913
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
I think it is ZODB corruption. See my post of a couple of weeks ago for suggestions for recovery. This the fourth example of ZClass related DB corruption that I've seen in the past six weeks. In my own brush with this, it seemed to be triggered by uninstalling and reinstalling products. Bill. On Wed, 8 Nov 2000, Chris McDonough wrote:
In your start script, set the STUPID_LOG_FILE environment variable to the path of a file to which you want log messages to be sent (before 'start' calls z2.py). Then review the log file. You'll probably get more clues as to what is going wrong, allowing you to fix the problem.
Error Type: Could not load oid ={, pickled data in traceback info may contain clues Error Value: None
----- Original Message ----- From: "Bill Welch" <bill@carbonecho.com> To: <zope@zope.org> Sent: Wednesday, November 08, 2000 1:58 PM Subject: Re: [Zope] Is data.fs corrupted?
I think it is ZODB corruption.
This is very unlikely. What makes you think this?
In my case, I couldn't import DemoPortal.zexp or Wizard.zexp from PTK because oid 1377 was already in use. The pickle dump that followed contained references to ZDiscussions, which I had deleted some time before. After deleting the offending products and their directories, restarting zope, and packing, I ran tranalyzer -r on my problem Data.fs. I found that the problem oid was in this transaction: "/Control_Panel/Products/manage_importObject import into /var/lib/zope/var/Data.fs from /var/lib/zope/import/ZDiscussions.zexp" referred to by this transaction: "Installed product DemoPortal" in turn, referred to by this tranaction: "Added Globals" I think ZODB corruption when I see a record in one product refer to a record in an independent product and when the transaction of a deleted product doesn't go away. On Wed, 8 Nov 2000, Chris McDonough wrote:
I think it is ZODB corruption.
This is very unlikely. What makes you think this?
I can see your point, but it's not quite correct to call this "ZODB corruption". This was (and is) related to a Zope programming error. Perhaps ZDiscussion.zexp does some funky things in instance space on an import that it shouldn't do. I imagine if we unraveled this far enough that we could pick the error out (not going to try :-). I'd argue that the ZODB is a very independent component of Zope, and it shouldn't be blamed for this. Devil's advocate question: if your Perl application failed because it couldn't find a record in an Oracle database, would you immediately chalk this up to database corruption and Oracle? We do clearly need to work on Zope tools to make it easier to find and clear "orphaned" instances in the ZODB. We should also try to weed out the programming errors which cause interdependencies of seemingly unrelated components of the same Zope instance that cause failures like this. Transactions are only tangentially related to this issue (I'm not sure how the "Added globals" transaction 'referred to' the "Installed product DemoPortal" transaction in your example, BTW). BTW, I'm being sort of pedantic because when people hear "ZODB" and "corruption" in the same sentence, they tend to get scared and think of ZODB as "unstable" which is really not the case... most purported "ZODB corruption" issues are caused by programming errors in Products. This has been the case for at least every one but one (the >2G pointer bug) that I've personally seen. ----- Original Message ----- From: "Bill Welch" <bill@carbonecho.com> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope@zope.org> Sent: Wednesday, November 08, 2000 2:59 PM Subject: Re: [Zope] Is data.fs corrupted?
In my case, I couldn't import DemoPortal.zexp or Wizard.zexp from PTK because oid 1377 was already in use. The pickle dump that followed contained references to ZDiscussions, which I had deleted some time before.
After deleting the offending products and their directories, restarting zope, and packing, I ran tranalyzer -r on my problem Data.fs. I found that the problem oid was in this transaction:
"/Control_Panel/Products/manage_importObject
import into /var/lib/zope/var/Data.fs from /var/lib/zope/import/ZDiscussions.zexp"
referred to by this transaction:
"Installed product DemoPortal"
in turn, referred to by this tranaction:
"Added Globals"
I think ZODB corruption when I see a record in one product refer to a record in an independent product and when the transaction of a deleted product doesn't go away.
On Wed, 8 Nov 2000, Chris McDonough wrote:
I think it is ZODB corruption.
This is very unlikely. What makes you think this?
Here's my evidence. A record (OID 0) in the "Added Globals" transaction refers to a record (OID 57) in the "Installed product DemoPortal" transaction.
From tranalyzer -r
TID: 33140200A4749F8 @ 69694 obs 1 len 274 (status 'p') By [Zope] "Added Globals" OID: 0 len 204 2, 57 TID: 3374475482BCF4C @ 3697235 obs 2 len 648 (status 'p') By [Zope] "Installed product DemoPortal" OID: 137f len 456 1377, 43ed, 43f3, 4431 135e, 43f0, 4389, 1568 442e, 1565 OID: 57 len 65 137f On Wed, 8 Nov 2000, Chris McDonough wrote:
Transactions are only tangentially related to this issue (I'm not sure how the "Added globals" transaction 'referred to' the "Installed product DemoPortal" transaction in your example, BTW).
I'm going to take a guess. It would appear AFAICT that the ZDiscussions product installed an object which it hung off the root object (the application object) when it was first imported. Maybe it was trying to make some sort of a singleton by doing so, where the singleton was *not* a Zope-manageable object (and thus it can't be seen or found via ZopeFind). When the product was deleted, it did not clean up after itself properly (specifically, it did not delete this singleton). While I don't completely understand the relationship between ZDiscussions and DemoPortal in this case (I *really* don't understand why you couldn't subsequently import DemoPortal or Wizard), I think if we dug hard enough we'd find at the bottom of it a problem like this. The point being that I'd bet we'd find a programming error staring at us in this sequence of events if we looked hard enough. Though it's tempting to call it a "ZODB corruption" problem, if you really get down to the lower levels, it's likely an application-level problem. That said, I'll admit that this distinction is really pedantic when your Zope doesn't work. :-) I'm glad you had the gumption to figure it out... ----- Original Message ----- From: "Bill Welch" <bill@carbonecho.com> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope@zope.org> Sent: Wednesday, November 08, 2000 4:21 PM Subject: Re: [Zope] Is data.fs corrupted?
Here's my evidence. A record (OID 0) in the "Added Globals" transaction refers to a record (OID 57) in the "Installed product DemoPortal" transaction.
From tranalyzer -r
TID: 33140200A4749F8 @ 69694 obs 1 len 274 (status 'p') By [Zope] "Added Globals" OID: 0 len 204 2, 57
TID: 3374475482BCF4C @ 3697235 obs 2 len 648 (status 'p') By [Zope] "Installed product DemoPortal" OID: 137f len 456 1377, 43ed, 43f3, 4431 135e, 43f0, 4389, 1568 442e, 1565 OID: 57 len 65 137f
On Wed, 8 Nov 2000, Chris McDonough wrote:
Transactions are only tangentially related to this issue (I'm not sure how the "Added globals" transaction 'referred to' the "Installed product DemoPortal" transaction in your example, BTW).
Chris McDonough wrote:
I'm going to take a guess. It would appear AFAICT that the ZDiscussions product installed an object which it hung off the root object (the application object) when it was first imported.
Don't rememebr seeing anything like this in ZDiscussions when I was looking over the code...
The point being that I'd bet we'd find a programming error staring at us in this sequence of events if we looked hard enough. Though it's tempting to call it a "ZODB corruption" problem, if you really get down to the lower levels, it's likely an application-level problem.
Maybe it's a Zope-level rather than ZODB level problem? Maybe some of the ZClass machinery or product registration machinery is screwing things up? Given that people have reported this from more than one product now, I'd be inclined to think it's not random bits of bad code in products. Maybe there's a method/pattern which used to be okay/recommended which is now causing problems? cheers, Chris
On Fri, 10 Nov 2000, Chris Withers wrote:
Chris McDonough wrote:
I'm going to take a guess. It would appear AFAICT that the ZDiscussions product installed an object which it hung off the root object (the application object) when it was first imported.
Don't rememebr seeing anything like this in ZDiscussions when I was looking over the code...
The point being that I'd bet we'd find a programming error staring at us in this sequence of events if we looked hard enough. Though it's tempting to call it a "ZODB corruption" problem, if you really get down to the lower levels, it's likely an application-level problem.
Maybe it's a Zope-level rather than ZODB level problem? Maybe some of the ZClass machinery or product registration machinery is screwing things up?
Given that people have reported this from more than one product now, I'd be inclined to think it's not random bits of bad code in products. Maybe there's a method/pattern which used to be okay/recommended which is now causing problems?
FWIW, I can also report this problem with ZDiscussions. In my case it stemmed from not properly deleting the ZDiscussion product before moving my Data.fs from 2.1.6 to 2.2.1 (I think). The symptom then was beeing unable to create ZSQL Methods (!) because of a missing ../Products/ZDBase/ZDiscussions.py file which I "fixed" by installing ZDBase again. I can however NOT import the ZDiscussions.zexp anymore because of "Duplicate Class Ids". Oh well, Stefan
FWIW, I can also report this problem with ZDiscussions. In my case it stemmed from not properly deleting the ZDiscussion product before moving my Data.fs from 2.1.6 to 2.2.1 (I think). The symptom then was beeing unable to create ZSQL Methods (!) because of a missing ../Products/ZDBase/ZDiscussions.py file which I "fixed" by installing ZDBase again
Man that's weird. But it's good info. Does the current PTK include ZDiscussions?
I can however NOT import the ZDiscussions.zexp anymore because of "Duplicate Class Ids".
So it looks like a ZClass didn't get cleaned up properly when you deleted the ZDiscussions through-the-web product. It might mean that there's a reference to an object in that area somewhere else in the ZODB. It'd be interesting for someone (not me, I'm booked) to think about how to write a tool that could detect orphaned instances and "strange" references in the ZODB.
Chris McDonough wrote:
FWIW, I can also report this problem with ZDiscussions. In my case it stemmed from not properly deleting the ZDiscussion product before moving my Data.fs from 2.1.6 to 2.2.1 (I think). The symptom then was beeing unable to create ZSQL Methods (!) because of a missing ../Products/ZDBase/ZDiscussions.py file which I "fixed" by installing ZDBase again
Man that's weird. But it's good info. Does the current PTK include ZDiscussions?
No Chris :-)
On Fri, 10 Nov 2000, Chris McDonough wrote:
FWIW, I can also report this problem with ZDiscussions. In my case it stemmed from not properly deleting the ZDiscussion product before moving my Data.fs from 2.1.6 to 2.2.1 (I think). The symptom then was beeing unable to create ZSQL Methods (!) because of a missing ../Products/ZDBase/ZDiscussions.py file which I "fixed" by installing ZDBase again
Man that's weird. But it's good info. Does the current PTK include ZDiscussions?
Ah yes, I also had some PTK version installed in the 2.1.6 Zope; in case this might be of importance.
I can however NOT import the ZDiscussions.zexp anymore because of "Duplicate Class Ids".
So it looks like a ZClass didn't get cleaned up properly when you deleted the ZDiscussions through-the-web product. It might mean that there's a reference to an object in that area somewhere else in the ZODB.
I believe I *did not* delete ZDiscussions, but brought my Data.fs to 2.2.1 without having the product installed there. Operator error, I suppose ;) Funny thing is that I did not *use* any ZDiscussions, PTK or whatever objects (anymore), just had the products hang around thinking they were stale anyway... Regards, Stefan
Maybe it's a Zope-level rather than ZODB level problem? Maybe some of the ZClass machinery or product registration machinery is screwing things up?
This is possible. Maybe even likely.
Given that people have reported this from more than one product now, I'd be inclined to think it's not random bits of bad code in products. Maybe there's a method/pattern which used to be okay/recommended which is now causing problems?
Some of the product registration code has been overhauled by Tres Seaver lately.. I wonder if he spotted anything that would have caused something like this.
Chris McDonough wrote:
Given that people have reported this from more than one product now, I'd be inclined to think it's not random bits of bad code in products. Maybe there's a method/pattern which used to be okay/recommended which is now causing problems?
Some of the product registration code has been overhauled by Tres Seaver lately.. I wonder if he spotted anything that would have caused something like this.
Hope he didn't cause it ;-) *cheeky grinz* Chris
Could I just butt in here and try and clarify what I've understood from this thread so far? I'm feeling a bit dumb about it but I'd really like to sort it out. 1) This problem is definitely a programming error 2) It arises when a product has a component which isn't 'registered' as a zope object, so it's not cleaned up when the product is deleted Is that right? What would 'registered as a zope object' mean in this situation? Are there any other circumstances under which you end up with orphaned instances? *how can it be fixed?* What I really don't understand is why seemingly unrelated products fail as a result of the orphan instances. Is is because new products are trying to get an oid which happens to be used by the orphan? If so, I don't think it's really so wrong to call this ZODB corruption, although I take your point about the ZODB being stable. In your perl analogy, it's as if you are using two tables to create a parent / child , one to many relationship. You then deleted a parent row but forgot to delete the corresponding child rows. You data is now corrupted. True to your analogy, this arises in sloppy programming, not in Oracle or whatever. However, when you create the tables in Oracle, you can place constraints on the tables so enforce the integrity of your data, to protect against this kind of programming. In a similar way, I think it's too easy to end up with corrupted data in the ZODB. Or perhaps I'm just particularly unlucky in the products I choose to use? cheers, seb
I'd argue that the ZODB is a very independent component of Zope, and it shouldn't be blamed for this. Devil's advocate question: if your Perl application failed because it couldn't find a record in an Oracle database, would you immediately chalk this up to database corruption and Oracle?
We do clearly need to work on Zope tools to make it easier to find and clear "orphaned" instances in the ZODB. We should also try to weed out the programming errors which cause interdependencies of seemingly unrelated components of the same Zope instance that cause failures like this. Transactions are only tangentially related to this issue (I'm not sure how the "Added globals" transaction 'referred to' the "Installed product DemoPortal" transaction in your example, BTW).
BTW, I'm being sort of pedantic because when people hear "ZODB" and "corruption" in the same sentence, they tend to get scared and think of ZODB as "unstable" which is really not the case... most purported "ZODB corruption" issues are caused by programming errors in Products. This has been the case for at least every one but one (the >2G pointer bug) that I've personally seen.
----- Original Message ----- From: "Bill Welch" <bill@carbonecho.com> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope@zope.org> Sent: Wednesday, November 08, 2000 2:59 PM Subject: Re: [Zope] Is data.fs corrupted?
In my case, I couldn't import DemoPortal.zexp or Wizard.zexp from PTK because oid 1377 was already in use. The pickle dump that followed contained references to ZDiscussions, which I had deleted some time before.
After deleting the offending products and their directories, restarting zope, and packing, I ran tranalyzer -r on my problem Data.fs. I found that the problem oid was in this transaction:
"/Control_Panel/Products/manage_importObject
import into /var/lib/zope/var/Data.fs from /var/lib/zope/import/ZDiscussions.zexp"
referred to by this transaction:
"Installed product DemoPortal"
in turn, referred to by this tranaction:
"Added Globals"
I think ZODB corruption when I see a record in one product refer to a record in an independent product and when the transaction of a deleted product doesn't go away.
On Wed, 8 Nov 2000, Chris McDonough wrote:
I think it is ZODB corruption.
This is very unlikely. What makes you think this?
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Could I just butt in here and try and clarify what I've understood from this thread so far? I'm feeling a bit dumb about it but I'd really like to sort it out.
1) This problem is definitely a programming error
I believe that, yes.
2) It arises when a product has a component which isn't 'registered' as a zope object, so it's not cleaned up when the product is deleted
Is that right? What would 'registered as a zope object' mean in this situation? Are there any other circumstances under which you end up with orphaned instances? *how can it be fixed?*
Zope objects basically need to inherit from OFS.SimpleItem (or an analogue) for them to be "web manageable". If a non-builtin Python object inherits only from the "Persistent" class, it can be saved into the ZODB, but it will not show up in the web interface unless you define certain methods on it to make it act like a "SimpleItem", and unless you add it to some internal Zope data structures that populate its ZODB container (such as the ObjectManager's "_objects" list). This is generally done for you by Zope and you need not think about it. But problems may happen when an application places instances into the ZODB of non-web-manageable, non-builtin objects as attributes of normal Zope objects. If these instances aren't cleaned up in the process of the deletion of whatever bit of Python code created them, they're "orphaned". When they're orphaned, some application code may attempt to initialize the object's instance (for whatever reason) in order to make use of them, and because the ZODB can't find the class of the instance, it complains. It complains by raising an exception. Zope's supposed to catch this and do the right thing, but it evidently doesn't sometimes. You can "fix it" by restoring whatever class the instance depends on and subsequently use the debugger to delete the instance from the ZODB. But I've had it happen to me where it was just easier to truncate the FileStorage I was working on than figure out exactly what was going on. This is bad.
What I really don't understand is why seemingly unrelated products fail as a result of the orphan instances.
Neither do I completely. This may be bad exception handling in Zope itself. When a Product is initialized, sometimes you'll see the failure of one Product initialization break others. Usually, it's the case that these Products *are* related in some way. It'd be interesting to investigate some of these failures where the failure to load an object seems to break other "unrelated" objects. I'd imagine we'd find an unobvious relation between the two objects.
Is is because new products are trying to get an oid which happens to be used by the orphan?
No... the ZODB manages the distribution of oids, Products never need worry about them.
If so, I don't think it's really so wrong to call this ZODB corruption, although I take your point about the ZODB being stable. In your perl analogy, it's as if you are using two tables to create a parent / child , one to many relationship. You then deleted a parent row but forgot to delete the corresponding child rows. You data is now corrupted. True to your analogy, this arises in sloppy programming, not in Oracle or whatever. However, when you create the tables in Oracle, you can place constraints on the tables so enforce the integrity of your data, to protect against this kind of programming. In a similar way, I think it's too easy to end up with corrupted data in the ZODB. Or perhaps I'm just particularly unlucky in the products I choose to use?
I think it's safe to say that you probably need to pay more attention when writing ZODB-based apps because you don't have things like constraints to prevent you from shooting yourself in the feet with both barrels. :-) That said, it'd probably be more accurate to call the result of this family of errors "Zope corruption" than "ZODB corruption". Again, I don't disagree that this distinction is really superpedantic on some level. It would appear that we need to work on Zope exception handling as well as tools to detect and delete orphaned instances. But we probably do not need to work on "making ZODB more stable" (don't kill the messenger! :-)
cheers,
seb
I'd argue that the ZODB is a very independent component of Zope, and it shouldn't be blamed for this. Devil's advocate question: if your Perl application failed because it couldn't find a record in an Oracle
database,
would you immediately chalk this up to database corruption and Oracle?
We do clearly need to work on Zope tools to make it easier to find and clear "orphaned" instances in the ZODB. We should also try to weed out the programming errors which cause interdependencies of seemingly unrelated components of the same Zope instance that cause failures like this. Transactions are only tangentially related to this issue (I'm not sure how the "Added globals" transaction 'referred to' the "Installed product DemoPortal" transaction in your example, BTW).
BTW, I'm being sort of pedantic because when people hear "ZODB" and "corruption" in the same sentence, they tend to get scared and think of ZODB as "unstable" which is really not the case... most purported "ZODB corruption" issues are caused by programming errors in Products. This has been the case for at least every one but one (the >2G pointer bug) that I've personally seen.
----- Original Message ----- From: "Bill Welch" <bill@carbonecho.com> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope@zope.org> Sent: Wednesday, November 08, 2000 2:59 PM Subject: Re: [Zope] Is data.fs corrupted?
In my case, I couldn't import DemoPortal.zexp or Wizard.zexp from PTK because oid 1377 was already in use. The pickle dump that followed contained references to ZDiscussions, which I had deleted some time before.
After deleting the offending products and their directories, restarting zope, and packing, I ran tranalyzer -r on my problem Data.fs. I found that the problem oid was in this transaction:
"/Control_Panel/Products/manage_importObject
import into /var/lib/zope/var/Data.fs from /var/lib/zope/import/ZDiscussions.zexp"
referred to by this transaction:
"Installed product DemoPortal"
in turn, referred to by this tranaction:
"Added Globals"
I think ZODB corruption when I see a record in one product refer to a record in an independent product and when the transaction of a deleted product doesn't go away.
On Wed, 8 Nov 2000, Chris McDonough wrote:
I think it is ZODB corruption.
This is very unlikely. What makes you think this?
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Eyeballing my problem Data.fs (I kept a copy), I see something different than you describe. What I take to be the root object (OID 0) refers to a record in what appears to an instance of something to do with PTK (OID 57). A separate record in the PTK related instance (PRI) refers to a record in what seems to be the ZDiscussions *ZClass*, not an instance of ZDiscussions. Interesting that the first (and problem) record of the PRI has the next OID after that of the last OID of the ZClass. Could it have orginally been part of the ZDiscussions install? I don't remember when I installed what. See snippets of dump and tranlyzer at end of message. N.B., the Data.fs is from an Intel machine (you have to swap bytes on the hex side to read it correctly). I tried the reinstall, delete instances method with no improvement. It didn't seem to me that truncating would have helped me either, considering that I would have had to truncate back to and including the root :-). I recovered by exporting all my objects, starting a new ZODB, and importing my objects. Bill. On Thu, 9 Nov 2000, Chris McDonough wrote:
But problems may happen when an application places instances into the ZODB of non-web-manageable, non-builtin objects as attributes of normal Zope objects. If these instances aren't cleaned up in the process of the deletion of whatever bit of Python code created them, they're "orphaned". When they're orphaned, some application code may attempt to initialize the object's instance (for whatever reason) in order to make use of them, and because the ZODB can't find the class of the instance, it complains. It complains by raising an exception. Zope's supposed to catch this and do the right thing, but it evidently doesn't sometimes.
You can "fix it" by restoring whatever class the instance depends on and subsequently use the debugger to delete the instance from the ZODB. But I've had it happen to me where it was just easier to truncate the FileStorage I was working on than figure out exactly what was going on. This is bad.
TID: 33140200A4749F8 @ 69694 obs 1 len 274 (status 'p') By [Zope] "Added Globals" OID: 0 len 204 2, 57 0069680 7d0b 0c71 2e75 0000 0000 0000 e404 3103 >.}q.u..........1< 0069696 1f40 b8f5 08b6 0000 0000 0000 1a01 0070 >@.............p.< 0069712 0000 000d 4100 6464 6465 4720 6f6c 6162 >.....Added Globa< 0069728 736c 0000 0000 0000 0000 3103 1f40 b8f5 >ls.........1@...< 0069744 08b6 0000 0000 0000 0000 0000 0000 0100 >................< 0069760 3e10 0000 0000 0000 0000 cc00 2828 0b55 >.>..........((U.< 0069776 6550 7372 7369 6574 636e 7165 5501 5011 >Persistenceq.U.P< 0069792 7265 6973 7473 6e65 4d74 7061 6970 676e >ersistentMapping< 0069808 0271 7174 4e03 2e74 717d 5504 5f0a 6f63 >q.tq.Nt.}q.U._co< 0069824 746e 6961 656e 7172 7d05 0671 5528 5f0a >ntainerq.}q.(U._< 0069840 6170 6b63 745f 6d69 7165 4707 cb41 1497 >pack_timeq.GA...< 0069856 5662 9cc2 0b55 7041 6c70 6369 7461 6f69 >bV..U.Applicatio< 0069872 716e 2808 0855 0000 0000 0000 0200 0971 >nq.(U.........q.< 0069888 5528 4f0f 5346 412e 7070 696c 6163 6974 >(U.OFS.Applicati< TID: 3374475482BCF4C @ 3769401 obs 2 len 648 (status 'p') By [Zope] "Installed product DemoPortal" OID: 137f len 456 1377, 43ed, 43f3, 4431 135e, 43f0, 4389, 1568 442e, 1565 OID: 57 len 65 137f 3769392 002e 0000 0000 a100 036a 4437 4875 cf2b >........j.7DuH+.< 3769408 004c 0000 0000 0200 7090 0000 1c00 0000 >L........p......< 3769424 6e49 7473 6c61 656c 2064 7270 646f 6375 >Installed produc< 3769440 2074 6544 6f6d 6f50 7472 6c61 0000 0000 >t DemoPortal....< 3769456 0000 7f13 3703 7544 2b48 4ccf 0000 0000 >.....7DuH+.L....< 3769472 0000 0000 0000 0000 3900 3984 0000 0000 >.........9.9....< 3769488 0000 0000 c801 2828 0555 5442 6572 7165 >......((U.BTreeq< 3769504 5501 4206 6375 656b 7174 7402 0371 744e >.U.Bucketq.tq.Nt< 3769520 282e 5528 2a19 3337 6962 7071 4941 5132 >.((U.*73biqpAI2Q< 3769536 6144 6932 504b 7469 3576 6737 3d3d 0471 >Da2iKPitv57g==q.< 3769552 1955 432a 5677 2f42 6536 7550 6f33 656b >U.*CwVB/6ePu3oke< 3769568 4f41 7973 4668 4342 3d51 713d 5505 2a19 >AOsyhFBCQ==q.U.*< 3769584 614d 6d73 636b 4c45 6977 5851 5833 7669 >MasmkcELwiQX3Xiv< 3769600 3353 556d 7751 3d3d 0671 1955 592a 502f >S3mUQw==q.U.*Y/P< 3769616 694c 6f65 5854 6164 6e4a 3871 7672 6f4c >LieoTXdaJnq8rvLo< 3769632 3358 3d67 713d 5507 2a19 6659 4932 6744 >X3g==q.U.*Yf2IDg< 3769648 5879 4c70 5346 6e2f 6270 316e 6c37 4135 >yXpLFS/npbn17l5A< 3769664 3d3d 0871 1955 632a 354a 7161 3463 6a36 >==q.U.*cJ5aqc46j< 3769680 3570 634c 494c 5a38 5a6a 5471 3d51 713d >p5LcLI8ZjZqTQ==q< 3769696 5509 2a19 356a 5a36 6f41 444e 5354 6b2f >.U.*j56ZAoNDTS/k< 3769712 4772 5330 4330 7363 415a 3d3d 0a71 1955 >rG0S0CcsZA==q.U.< 3769728 6a2a 3647 3263 7848 4251 734c 4a6b 3153 >*jG6c2HxQBLskJS1< 3769744 7730 6c61 6e4f 3d77 713d 550b 2a19 5773 >0walOnw==q.U.*sW< 3769760 5133 6b78 466a 5156 4e50 4d4b 7555 3042 >3QxkjFVQPNKMUuB0< 3769776 3762 7741 3d3d 0c71 1955 792a 4c38 6347 >b7Aw==q.U.*y8LGc< 3769792 7a50 5745 2f47 4933 5244 4d4b 4551 3835 >PzEWG/3IDRKMQE58< 3769808 3d77 713d 740d 5528 0008 0000 0000 1300 >w==q.t(U........< 3769824 7177 510e 0855 0000 0000 0000 ed43 0f71 >wq.QU.......C.q.< 3769840 5551 0008 0000 0000 4300 71f3 5110 0855 >QU.......C.q.QU.< 3769856 0000 0000 0000 3144 1171 5551 0008 0000 >......D1q.QU....< 3769872 0000 1300 715e 5112 0855 0000 0000 0000 >....^q.QU.......< 3769888 f043 1371 5551 0008 0000 0000 4300 7189 >C.q.QU.......C.q< 3769904 5114 0855 0000 0000 0000 6815 1571 5551 >.QU........hq.QU< 3769920 0008 0000 0000 4400 712e 5116 0855 0000 >.......D.q.QU...< 3769936 0000 0000 6515 1771 7451 7174 2e18 0000 >.....eq.Qttq....< 3769952 0000 0000 5700 3703 7544 2b48 4ccf 0000 >.....W.7DuH+.L..< 3769968 0000 0000 0000 0000 0000 3900 3984 0000 >...........9.9..< 3769984 0000 0000 0000 4100 2828 0555 5442 6572 >.......A((U.BTre< 3770000 7165 5501 4205 7254 6565 0271 7174 4e03 >eq.U.BTreeq.tq.N< 3770016 2e74 2828 284e 0855 0000 0000 0000 7f13 >t.((N(U.........< 3770032 0471 6828 5501 4206 6375 656b 7174 7405 >q.(h.U.Bucketq.t< 3770048 5174 0a4b 7474 0671 002e 0000 0000 0200 >tQK.ttq.........< 3770064 0390 4437 7a82 f666 00f7 0000 0000 2100 >..7D.zf........!< TID: 3364E8A614C1CC5 @ 384103 obs 35 len 32471 (status 'p') By superuser "/Control_Panel/Products/manage_importObject import into /var/lib/zope/var/Data.fs from /var/lib/zope/import/ZDiscussions.zexp" OID: 135b len 488 135d, 135e, 135f, 1360 OID: 135d len 255 OID: 135e len 1795 1361, 135d, 1363, 1364 1365, 1366, 1367, 1368 1362 OID: 135f len 327 OID: 1360 len 206 135f, 1369, 136a OID: 1361 len 1164 136b, 136d, 1373, 136c 136f, 1370, 1371, 1372 136e, 1374, 1375 OID: 1362 len 547 OID: 1363 len 21 135d OID: 1364 len 1534 OID: 1365 len 1107 OID: 1366 len 484 1376, 1377, 1378, 1379 OID: 1367 len 243 OID: 1368 len 845 OID: 1369 len 57 OID: 136a len 380 OID: 136b len 730 OID: 136c len 383 OID: 136d len 1799 OID: 136e len 1291 OID: 136f len 1836 OID: 1370 len 2178 OID: 1371 len 1812 OID: 1372 len 2484 OID: 1373 len 305 OID: 1374 len 2164 OID: 1375 len 3213 OID: 1376 len 253 OID: 1377 len 900 1376, 137a, 137b, 137c OID: 1378 len 325 OID: 1379 len 206 1378, 137d, 137e OID: 137a len 21 1376 OID: 137b len 206 OID: 137c len 1084 OID: 137d len 57 OID: 137e len 150 0384096 0000 0000 5c00 0371 4e36 9e89 e3b3 003b >.....\q.6N....;.< 0384112 0000 0000 7e00 70df 0a00 7e00 0000 7a20 >.....~.p...~.. z< 0384128 706f 7265 6f72 746f 432f 6e6f 7274 6c6f >operroot/Control< 0384144 505f 6e61 6c65 502f 6f72 7564 7463 2f73 >_Panel/Products/< 0384160 616d 616e 6567 695f 706d 726f 4f74 6a62 >manage_importObj< 0384176 6365 0a74 690a 706d 726f 2074 6e69 6f74 >ect..import into< 0384192 2f20 6176 2f72 696c 2f62 6f7a 6570 762f > /var/lib/zope/v< 0384208 7261 442f 7461 2e61 7366 6620 6f72 206d >ar/Data.fs from < 0384224 762f 7261 6c2f 6269 7a2f 706f 2f65 6d69 >/var/lib/zope/im< 0384240 6f70 7472 5a2f 6944 6373 7375 6973 6e6f >port/ZDiscussion< 0384256 2e73 657a 7078 0000 0000 0000 5b13 3603 >s.zexp.......[.6< 0384272 894e b39e 3be3 0000 0000 0000 0000 0000 >N....;..........< 0384288 0000 0500 67dc 0000 0000 0000 0000 e801 >.....g..........< 0384304 2828 0f55 435a 616c 7373 7365 5a2e 6c43 >((U.ZClasses.ZCl< 0384320 7361 7173 5501 5a06 6c43 7361 7173 7402 >assq.U.ZClassq.t< 0384336 0371 744e 7d2e 0471 5528 5f11 6570 6d72 >q.Nt.}q.(U._perm< 0384352 7369 6973 6e6f 614d 7070 7265 0571 4163 >issionMapperq.cA< 0384368 6363 7365 4373 6e6f 7274 6c6f 502e 7265 >ccessControl.Per< 0384384 696d 7373 6f69 4d6e 7061 6970 676e 500a >missionMapping.P< 0384400 0a4d 0671 524e 0771 717d 5508 5f22 7243 >M.q.NRq.}q.U"_Cr< 0384416 6165 6574 635f 616c 7373 695f 736e 6174 >eate_class_insta< 0384432 636e 7365 505f 7265 696d 7373 6f69 716e >nces_Permissionq< 0384448 5509 5f23 6441 5f64 445a 7369 7563 7373 >.U#_Add_ZDiscuss< 0384464 6f69 736e 545f 706f 6369 5f73 6550 6d72 >ions_Topics_Perm< 0384480 7369 6973 6e6f 0a71 6273 1c55 7a5f 6c63 >issionq.sbU._zcl< . . . 0413296 002e 0000 0000 1300 0377 4e36 9e89 e3b3 >........w.6N....< 0413312 003b 0000 0000 0000 0000 0000 0000 dc05 >;...............< 0413328 0067 0000 0000 0000 0300 2884 4563 7478 >g..........(cExt< 0413344 6e65 6973 6e6f 6c43 7361 0a73 7845 6574 >ensionClass.Exte< 0413360 736e 6f69 436e 616c 7373 710a 2801 0655 >nsionClass.q.(U.< 0413376 445a 7449 6d65 0271 6328 435a 616c 7373 >ZDItemq.(cZClass< 0413392 7365 5a2e 6c43 7361 0a73 6550 7372 7369 >es.ZClass.Persis< 0413408 6574 746e 6c43 7361 0a73 0371 5063 6f72 >tentClass.q.cPro< 0413424 7564 7463 2e73 445a 6142 6573 5a2e 6944 >ducts.ZDBase.ZDi< 0413440 6373 7375 6973 6e6f 0a73 445a 7449 6d65 >scussions.ZDItem< 0413456 710a 6304 464f 2e53 6953 706d 656c 7449 >.q.cOFS.SimpleIt< 0413472 6d65 530a 6d69 6c70 4965 6574 0a6d 0571 >em.SimpleItem.q.< 0413488 7174 7d06 0771 5528 6904 6f63 716e 5508 >tq.}q.(U.iconq.U< 0413504 4357 6e6f 7274 6c6f 505f 6e61 6c65 502f >WControl_Panel/P< 0413520 6f72 7564 7463 2f73 445a 7369 7563 7373 >roducts/ZDiscuss< 0413536 6f69 736e 5a2f 5444 706f 6369 702f 6f72 >ions/ZDTopic/pro< 0413552 6570 7472 7379 6568 7465 2f73 656d 6874 >pertysheets/meth< 0413568 646f 2f73 445a 7449 6d65 3225 2f30 697a >ods/ZDItem%20/zi< 0413584 6f63 496e 616d 6567 0971 0a55 705f 635f >conImageq.U._p_c< 0413600 6168 676e 6465 0a71 014b 0755 5f5f 6f64 >hangedq.K.U.__do< 0413616 5f63 715f 550b 5a11 6944 6373 7375 6973 >c__q.U.ZDiscussi< 0413632 6e6f 2073 7449 6d65 0c71 0655 705f 6f5f >ons Itemq.U._p_o< 0413648 6469 0d71 0855 0000 0000 0000 4c02 0e71 >idq.U........Lq.< 0413664 0955 656d 6174 745f 7079 7165 550f 5a11 >U.meta_typeq.U.Z< 0413680 6944 6373 7375 6973 6e6f 2073 7449 6d65 >Discussions Item< 0413696 1071 0e55 7270 706f 7265 7974 6873 6565 >q.U.propertyshee< 0413712 7374 1171 5528 0008 0000 0000 1300 717a >tsq.(U........zq< 0413728 2812 554e 0008 0000 0000 1300 7176 5113 >.(NU........vq.Q< 0413744 7174 7414 1571 5551 690a 646e 7865 685f >tq.tq.QU.index_h< 0413760 6d74 716c 6316 435a 616c 7373 7365 4d2e >tmlq.cZClasses.M< 0413776 7465 6f68 0a64 574d 710a 4e17 7152 7d18 >ethod.MW.q.NRq.}< 0413792 1971 2455 5a5f 6c43 7361 4d73 7465 6f68 >q.U$_ZClassMetho< 0413808 5064 7265 696d 7373 6f69 4d6e 7061 6570 >dPermissionMappe< 0413824 4d72 7465 6f68 5f64 1a71 5528 0008 0000 >rMethod_q.(U....< 0413840 0000 1300 717b 281b 0e55 464f 2e53 5444 >....{q.(U.OFS.DT< 0413856 4c4d 654d 6874 646f 1c71 4f63 5346 442e >MLMethodq.cOFS.D< 0413872 4d54 4d4c 7465 6f68 0a64 5444 4c4d 654d >TMLMethod.DTMLMe< 0413888 6874 646f 710a 741d 1e71 7174 511f 6273 >thod.q.tq.tq.Qsb< 0413904 0e55 616d 616e 6567 6f5f 7470 6f69 736e >U.manage_options< 0413920 2071 7d28 2171 5528 6c05 6261 6c65 2271 >q (}q!(U.labelq"< 0413936 0a55 7250 706f 7265 6974 7365 2371 0655 >U.Propertiesq#U.< 0413952 6361 6974 6e6f 2471 1555 616d 616e 6567 >actionq$U.manage< 0413968 705f 6f72 6570 7472 6569 4673 726f 716d >_propertiesFormq< 0413984 7525 717d 2826 0555 616c 6562 716c 5527 >%u}q&(U.labelq'U< 0414000 5308 6365 7275 7469 7179 5528 6106 7463 >.Securityq(U.act< 0414016 6f69 716e 5529 6d0d 6e61 6761 5f65 6361 >ionq)U.manage_ac< 0414032 6563 7373 2a71 7d75 2b71 6828 5527 5604 >cessq*u}q+(h'U.V< 0414048 6569 7177 682c 5529 690a 646e 7865 685f >iewq,h)U.index_h< 0414064 6d74 716c 752d 7174 552e 7a0a 6369 6e6f >tmlq-utq.U.zicon< 0414080 6d49 6761 7165 282f 0855 0000 0000 0000 >Imageq/(U.......< 0414096 7c13 3071 5528 4f09 5346 492e 616d 6567 >.|q0(U.OFS.Image< 0414112 3171 4f63 5346 492e 616d 6567 490a 616d >q1cOFS.Image.Ima< 0414128 6567 710a 7432 3371 7174 5134 1255 5f5f >ge.q2tq3tq4QU.__< 0414144 6361 705f 7265 696d 7373 6f69 736e 5f5f >ac_permissions__< 0414160 3571 5529 5f09 5f70 6573 6972 6c61 3671 >q5)U._p_serialq6< 0414176 0855 3003 6196 3bbc cc84 3771 0a55 5f5f >U..0.a.;..q7U.__< 0414192 6f6d 7564 656c 5f5f 3871 1955 372a 6233 >module__q8U.*73b< 0414208 7169 4170 3249 4451 3261 4b69 6950 7674 >iqpAI2QDa2iKPitv< 0414224 3735 3d67 713d 7539 7174 743a 4e2e 002e >57g==q9utq:t.N..< 0414240 0000 0000 1300 0378 4e36 9e89 e3b3 003b >......x.6N....;.< . . . 0416384 2e74 717d 2e04 0000 0000 0000 7e13 3603 >t.}q.........~.6< 0416400 894e b39e 3be3 0000 0000 0000 0000 0000 >N....;..........< 0416416 0000 0500 67dc 0000 0000 0000 0000 9600 >.....g..........< 0416432 2828 0f55 435a 616c 7373 7365 4d2e 7465 >((U.ZClasses.Met< 0416448 6f68 7164 5501 5a12 6c43 7361 4d73 7465 >hodq.U.ZClassMet< 0416464 6f68 7364 6853 6565 7174 7402 0371 744e >hodsSheetq.tq.Nt< 0416480 7d2e 0471 5528 5f03 646d 0571 717d 5506 >.}q.(U._mdq.}q.U< 0416496 5f08 626f 656a 7463 7173 2807 717d 2808 >._objectsq.(}q.(< 0416512 0955 656d 6174 745f 7079 7165 5509 440b >U.meta_typeq.U.D< 0416528 4d54 204c 654d 6874 646f 0a71 0255 6469 >TML Methodq.U.id< 0416544 0b71 0b55 6e69 6564 5f78 7468 6c6d 7120 >q.U.index_html q< 0416560 750c 5574 6902 7164 550d 6d07 7465 6f68 >.utU.idq.U.metho< 0416576 7364 0e71 2e75 0000 0000 0000 df7e 3603 >dsq.u.......~..6<
Bill Welch wrote:
Eyeballing my problem Data.fs (I kept a copy), I see something different than you describe.
What I take to be the root object (OID 0) refers to a record in what appears to an instance of something to do with PTK (OID 57).
Wow, nice dumps... So the root object contains a reference to oid 57, which appears to be an instance in Product land having to do with DemoPortal. For instance, maybe it's the ObjectManager instance related to the Product that goes into the Control_Panel.Products area. So... app.something = app.Control_Panel.Products.DemoPortal get_transaction().commit() ... just for instance. Why would somebody do this? I don't know. BTW, I think object 2 is the child object list.
A separate record in the PTK related instance (PRI) refers to a record in what seems to be the ZDiscussions *ZClass*, not an instance of ZDiscussions.
That's possible. Still assuming oid 57 is the ObjectManager instance related to the Product: app.Control_Panel.Products.DemoPortal.foo = app.Control_Panel.Products.ZDiscussions.propertysheets.methods.amethod get_transaction().commit() Why? I have no idea.
Interesting that the first (and problem) record of the PRI has the next OID after that of the last OID of the ZClass. Could it have orginally been part of the ZDiscussions install? I don't remember when I installed what.
To be honest, I have no frigging clue. :-) The "PRI" in your case is created on Zope startup. It's the persistent representation of the on-disk DemoPortal Product in the Control_Panel. Furthermore, it gets re-created every time Zope starts (unless you're using ZEO). There are talks about making on-disk products not have persistent representations in the control panel products folder (not that this would help your issue, but it might make things a little simpler).
See snippets of dump and tranlyzer at end of message. N.B., the Data.fs is from an Intel machine (you have to swap bytes on the hex side to read it correctly).
I tried the reinstall, delete instances method with no improvement. It didn't seem to me that truncating would have helped me either, considering that I would have had to truncate back to and including the root :-).
As I read your problem report, if you wanted to try to solve the problem via truncation, it seems you would have needed to chop the file at the byte previous to the beginning of the transaction which first installed the "PRI". I presume that was too early of a transaction to be feasible? It seems a pretty low number. Also, I presume this was an older version of Zope? You imported an object as superuser, which shouldn't be able to happen under Zope 2.2.X? Was this an older version of the PTK as well?
I recovered by exporting all my objects, starting a new ZODB, and importing my objects.
Bummer. :-( But I still think your problem was caused by app-level error and not ZODB-level error. If I had time, I'd examine ZDiscussions and the PTK to see if I could spot the problem. But I don't.
On Thu, 9 Nov 2000, Chris McDonough wrote:
But problems may happen when an application places instances into the ZODB of non-web-manageable, non-builtin objects as attributes of normal Zope objects. If these instances aren't cleaned up in the process of the deletion of whatever bit of Python code created them, they're "orphaned". When they're orphaned, some application code may attempt to initialize the object's instance (for whatever reason) in order to make use of them, and because the ZODB can't find the class of the instance, it complains. It complains by raising an exception. Zope's supposed to catch this and do the right thing, but it evidently doesn't sometimes.
You can "fix it" by restoring whatever class the instance depends on and subsequently use the debugger to delete the instance from the ZODB. But I've had it happen to me where it was just easier to truncate the FileStorage I was working on than figure out exactly what was going on. This is bad.
TID: 33140200A4749F8 @ 69694 obs 1 len 274 (status 'p') By [Zope] "Added Globals" OID: 0 len 204 2, 57
0069680 7d0b 0c71 2e75 0000 0000 0000 e404 3103 >.}q.u..........1< 0069696 1f40 b8f5 08b6 0000 0000 0000 1a01 0070 >@.............p.< 0069712 0000 000d 4100 6464 6465 4720 6f6c 6162 >.....Added Globa< 0069728 736c 0000 0000 0000 0000 3103 1f40 b8f5 >ls.........1@...< 0069744 08b6 0000 0000 0000 0000 0000 0000 0100 >................< 0069760 3e10 0000 0000 0000 0000 cc00 2828 0b55 >.>..........((U.< 0069776 6550 7372 7369 6574 636e 7165 5501 5011 >Persistenceq.U.P< 0069792 7265 6973 7473 6e65 4d74 7061 6970 676e >ersistentMapping< 0069808 0271 7174 4e03 2e74 717d 5504 5f0a 6f63 >q.tq.Nt.}q.U._co< 0069824 746e 6961 656e 7172 7d05 0671 5528 5f0a >ntainerq.}q.(U._< 0069840 6170 6b63 745f 6d69 7165 4707 cb41 1497 >pack_timeq.GA...< 0069856 5662 9cc2 0b55 7041 6c70 6369 7461 6f69 >bV..U.Applicatio< 0069872 716e 2808 0855 0000 0000 0000 0200 0971 >nq.(U.........q.< 0069888 5528 4f0f 5346 412e 7070 696c 6163 6974 >(U.OFS.Applicati<
TID: 3374475482BCF4C @ 3769401 obs 2 len 648 (status 'p') By [Zope] "Installed product DemoPortal" OID: 137f len 456 1377, 43ed, 43f3, 4431 135e, 43f0, 4389, 1568 442e, 1565 OID: 57 len 65 137f
3769392 002e 0000 0000 a100 036a 4437 4875 cf2b >........j.7DuH+.< 3769408 004c 0000 0000 0200 7090 0000 1c00 0000 >L........p......< 3769424 6e49 7473 6c61 656c 2064 7270 646f 6375 >Installed produc< 3769440 2074 6544 6f6d 6f50 7472 6c61 0000 0000 >t DemoPortal....< 3769456 0000 7f13 3703 7544 2b48 4ccf 0000 0000 >.....7DuH+.L....< 3769472 0000 0000 0000 0000 3900 3984 0000 0000 >.........9.9....< 3769488 0000 0000 c801 2828 0555 5442 6572 7165 >......((U.BTreeq< 3769504 5501 4206 6375 656b 7174 7402 0371 744e >.U.Bucketq.tq.Nt< 3769520 282e 5528 2a19 3337 6962 7071 4941 5132 >.((U.*73biqpAI2Q< 3769536 6144 6932 504b 7469 3576 6737 3d3d 0471 >Da2iKPitv57g==q.< 3769552 1955 432a 5677 2f42 6536 7550 6f33 656b >U.*CwVB/6ePu3oke< 3769568 4f41 7973 4668 4342 3d51 713d 5505 2a19 >AOsyhFBCQ==q.U.*< 3769584 614d 6d73 636b 4c45 6977 5851 5833 7669 >MasmkcELwiQX3Xiv< 3769600 3353 556d 7751 3d3d 0671 1955 592a 502f >S3mUQw==q.U.*Y/P< 3769616 694c 6f65 5854 6164 6e4a 3871 7672 6f4c >LieoTXdaJnq8rvLo< 3769632 3358 3d67 713d 5507 2a19 6659 4932 6744 >X3g==q.U.*Yf2IDg< 3769648 5879 4c70 5346 6e2f 6270 316e 6c37 4135 >yXpLFS/npbn17l5A< 3769664 3d3d 0871 1955 632a 354a 7161 3463 6a36 >==q.U.*cJ5aqc46j< 3769680 3570 634c 494c 5a38 5a6a 5471 3d51 713d >p5LcLI8ZjZqTQ==q< 3769696 5509 2a19 356a 5a36 6f41 444e 5354 6b2f >.U.*j56ZAoNDTS/k< 3769712 4772 5330 4330 7363 415a 3d3d 0a71 1955 >rG0S0CcsZA==q.U.< 3769728 6a2a 3647 3263 7848 4251 734c 4a6b 3153 >*jG6c2HxQBLskJS1< 3769744 7730 6c61 6e4f 3d77 713d 550b 2a19 5773 >0walOnw==q.U.*sW< 3769760 5133 6b78 466a 5156 4e50 4d4b 7555 3042 >3QxkjFVQPNKMUuB0< 3769776 3762 7741 3d3d 0c71 1955 792a 4c38 6347 >b7Aw==q.U.*y8LGc< 3769792 7a50 5745 2f47 4933 5244 4d4b 4551 3835 >PzEWG/3IDRKMQE58< 3769808 3d77 713d 740d 5528 0008 0000 0000 1300 >w==q.t(U........< 3769824 7177 510e 0855 0000 0000 0000 ed43 0f71 >wq.QU.......C.q.< 3769840 5551 0008 0000 0000 4300 71f3 5110 0855 >QU.......C.q.QU.< 3769856 0000 0000 0000 3144 1171 5551 0008 0000 >......D1q.QU....< 3769872 0000 1300 715e 5112 0855 0000 0000 0000 >....^q.QU.......< 3769888 f043 1371 5551 0008 0000 0000 4300 7189 >C.q.QU.......C.q< 3769904 5114 0855 0000 0000 0000 6815 1571 5551 >.QU........hq.QU< 3769920 0008 0000 0000 4400 712e 5116 0855 0000 >.......D.q.QU...< 3769936 0000 0000 6515 1771 7451 7174 2e18 0000 >.....eq.Qttq....< 3769952 0000 0000 5700 3703 7544 2b48 4ccf 0000 >.....W.7DuH+.L..< 3769968 0000 0000 0000 0000 0000 3900 3984 0000 >...........9.9..< 3769984 0000 0000 0000 4100 2828 0555 5442 6572 >.......A((U.BTre< 3770000 7165 5501 4205 7254 6565 0271 7174 4e03 >eq.U.BTreeq.tq.N< 3770016 2e74 2828 284e 0855 0000 0000 0000 7f13 >t.((N(U.........< 3770032 0471 6828 5501 4206 6375 656b 7174 7405 >q.(h.U.Bucketq.t< 3770048 5174 0a4b 7474 0671 002e 0000 0000 0200 >tQK.ttq.........< 3770064 0390 4437 7a82 f666 00f7 0000 0000 2100 >..7D.zf........!<
TID: 3364E8A614C1CC5 @ 384103 obs 35 len 32471 (status 'p') By superuser "/Control_Panel/Products/manage_importObject
import into /var/lib/zope/var/Data.fs from /var/lib/zope/import/ZDiscussions.zexp" OID: 135b len 488 135d, 135e, 135f, 1360 OID: 135d len 255 OID: 135e len 1795 1361, 135d, 1363, 1364 1365, 1366, 1367, 1368 1362 OID: 135f len 327 OID: 1360 len 206 135f, 1369, 136a OID: 1361 len 1164 136b, 136d, 1373, 136c 136f, 1370, 1371, 1372 136e, 1374, 1375 OID: 1362 len 547 OID: 1363 len 21 135d OID: 1364 len 1534 OID: 1365 len 1107 OID: 1366 len 484 1376, 1377, 1378, 1379 OID: 1367 len 243 OID: 1368 len 845 OID: 1369 len 57 OID: 136a len 380 OID: 136b len 730 OID: 136c len 383 OID: 136d len 1799 OID: 136e len 1291 OID: 136f len 1836 OID: 1370 len 2178 OID: 1371 len 1812 OID: 1372 len 2484 OID: 1373 len 305 OID: 1374 len 2164 OID: 1375 len 3213 OID: 1376 len 253 OID: 1377 len 900 1376, 137a, 137b, 137c OID: 1378 len 325 OID: 1379 len 206 1378, 137d, 137e OID: 137a len 21 1376 OID: 137b len 206 OID: 137c len 1084 OID: 137d len 57 OID: 137e len 150
0384096 0000 0000 5c00 0371 4e36 9e89 e3b3 003b >.....\q.6N....;.< 0384112 0000 0000 7e00 70df 0a00 7e00 0000 7a20 >.....~.p...~.. z< 0384128 706f 7265 6f72 746f 432f 6e6f 7274 6c6f >operroot/Control< 0384144 505f 6e61 6c65 502f 6f72 7564 7463 2f73 >_Panel/Products/< 0384160 616d 616e 6567 695f 706d 726f 4f74 6a62 >manage_importObj< 0384176 6365 0a74 690a 706d 726f 2074 6e69 6f74 >ect..import into< 0384192 2f20 6176 2f72 696c 2f62 6f7a 6570 762f > /var/lib/zope/v< 0384208 7261 442f 7461 2e61 7366 6620 6f72 206d >ar/Data.fs from < 0384224 762f 7261 6c2f 6269 7a2f 706f 2f65 6d69 >/var/lib/zope/im< 0384240 6f70 7472 5a2f 6944 6373 7375 6973 6e6f >port/ZDiscussion< 0384256 2e73 657a 7078 0000 0000 0000 5b13 3603 >s.zexp.......[.6< 0384272 894e b39e 3be3 0000 0000 0000 0000 0000 >N....;..........< 0384288 0000 0500 67dc 0000 0000 0000 0000 e801 >.....g..........< 0384304 2828 0f55 435a 616c 7373 7365 5a2e 6c43 >((U.ZClasses.ZCl< 0384320 7361 7173 5501 5a06 6c43 7361 7173 7402 >assq.U.ZClassq.t< 0384336 0371 744e 7d2e 0471 5528 5f11 6570 6d72 >q.Nt.}q.(U._perm< 0384352 7369 6973 6e6f 614d 7070 7265 0571 4163 >issionMapperq.cA< 0384368 6363 7365 4373 6e6f 7274 6c6f 502e 7265 >ccessControl.Per< 0384384 696d 7373 6f69 4d6e 7061 6970 676e 500a >missionMapping.P< 0384400 0a4d 0671 524e 0771 717d 5508 5f22 7243 >M.q.NRq.}q.U"_Cr< 0384416 6165 6574 635f 616c 7373 695f 736e 6174 >eate_class_insta< 0384432 636e 7365 505f 7265 696d 7373 6f69 716e >nces_Permissionq< 0384448 5509 5f23 6441 5f64 445a 7369 7563 7373 >.U#_Add_ZDiscuss< 0384464 6f69 736e 545f 706f 6369 5f73 6550 6d72 >ions_Topics_Perm< 0384480 7369 6973 6e6f 0a71 6273 1c55 7a5f 6c63 >issionq.sbU._zcl< . . . 0413296 002e 0000 0000 1300 0377 4e36 9e89 e3b3 >........w.6N....< 0413312 003b 0000 0000 0000 0000 0000 0000 dc05 >;...............< 0413328 0067 0000 0000 0000 0300 2884 4563 7478 >g..........(cExt< 0413344 6e65 6973 6e6f 6c43 7361 0a73 7845 6574 >ensionClass.Exte< 0413360 736e 6f69 436e 616c 7373 710a 2801 0655 >nsionClass.q.(U.< 0413376 445a 7449 6d65 0271 6328 435a 616c 7373 >ZDItemq.(cZClass< 0413392 7365 5a2e 6c43 7361 0a73 6550 7372 7369 >es.ZClass.Persis< 0413408 6574 746e 6c43 7361 0a73 0371 5063 6f72 >tentClass.q.cPro< 0413424 7564 7463 2e73 445a 6142 6573 5a2e 6944 >ducts.ZDBase.ZDi< 0413440 6373 7375 6973 6e6f 0a73 445a 7449 6d65 >scussions.ZDItem< 0413456 710a 6304 464f 2e53 6953 706d 656c 7449 >.q.cOFS.SimpleIt< 0413472 6d65 530a 6d69 6c70 4965 6574 0a6d 0571 >em.SimpleItem.q.< 0413488 7174 7d06 0771 5528 6904 6f63 716e 5508 >tq.}q.(U.iconq.U< 0413504 4357 6e6f 7274 6c6f 505f 6e61 6c65 502f >WControl_Panel/P< 0413520 6f72 7564 7463 2f73 445a 7369 7563 7373 >roducts/ZDiscuss< 0413536 6f69 736e 5a2f 5444 706f 6369 702f 6f72 >ions/ZDTopic/pro< 0413552 6570 7472 7379 6568 7465 2f73 656d 6874 >pertysheets/meth< 0413568 646f 2f73 445a 7449 6d65 3225 2f30 697a >ods/ZDItem%20/zi< 0413584 6f63 496e 616d 6567 0971 0a55 705f 635f >conImageq.U._p_c< 0413600 6168 676e 6465 0a71 014b 0755 5f5f 6f64 >hangedq.K.U.__do< 0413616 5f63 715f 550b 5a11 6944 6373 7375 6973 >c__q.U.ZDiscussi< 0413632 6e6f 2073 7449 6d65 0c71 0655 705f 6f5f >ons Itemq.U._p_o< 0413648 6469 0d71 0855 0000 0000 0000 4c02 0e71 >idq.U........Lq.< 0413664 0955 656d 6174 745f 7079 7165 550f 5a11 >U.meta_typeq.U.Z< 0413680 6944 6373 7375 6973 6e6f 2073 7449 6d65 >Discussions Item< 0413696 1071 0e55 7270 706f 7265 7974 6873 6565 >q.U.propertyshee< 0413712 7374 1171 5528 0008 0000 0000 1300 717a >tsq.(U........zq< 0413728 2812 554e 0008 0000 0000 1300 7176 5113 >.(NU........vq.Q< 0413744 7174 7414 1571 5551 690a 646e 7865 685f >tq.tq.QU.index_h< 0413760 6d74 716c 6316 435a 616c 7373 7365 4d2e >tmlq.cZClasses.M< 0413776 7465 6f68 0a64 574d 710a 4e17 7152 7d18 >ethod.MW.q.NRq.}< 0413792 1971 2455 5a5f 6c43 7361 4d73 7465 6f68 >q.U$_ZClassMetho< 0413808 5064 7265 696d 7373 6f69 4d6e 7061 6570 >dPermissionMappe< 0413824 4d72 7465 6f68 5f64 1a71 5528 0008 0000 >rMethod_q.(U....< 0413840 0000 1300 717b 281b 0e55 464f 2e53 5444 >....{q.(U.OFS.DT< 0413856 4c4d 654d 6874 646f 1c71 4f63 5346 442e >MLMethodq.cOFS.D< 0413872 4d54 4d4c 7465 6f68 0a64 5444 4c4d 654d >TMLMethod.DTMLMe< 0413888 6874 646f 710a 741d 1e71 7174 511f 6273 >thod.q.tq.tq.Qsb< 0413904 0e55 616d 616e 6567 6f5f 7470 6f69 736e >U.manage_options< 0413920 2071 7d28 2171 5528 6c05 6261 6c65 2271 >q (}q!(U.labelq"< 0413936 0a55 7250 706f 7265 6974 7365 2371 0655 >U.Propertiesq#U.< 0413952 6361 6974 6e6f 2471 1555 616d 616e 6567 >actionq$U.manage< 0413968 705f 6f72 6570 7472 6569 4673 726f 716d >_propertiesFormq< 0413984 7525 717d 2826 0555 616c 6562 716c 5527 >%u}q&(U.labelq'U< 0414000 5308 6365 7275 7469 7179 5528 6106 7463 >.Securityq(U.act< 0414016 6f69 716e 5529 6d0d 6e61 6761 5f65 6361 >ionq)U.manage_ac< 0414032 6563 7373 2a71 7d75 2b71 6828 5527 5604 >cessq*u}q+(h'U.V< 0414048 6569 7177 682c 5529 690a 646e 7865 685f >iewq,h)U.index_h< 0414064 6d74 716c 752d 7174 552e 7a0a 6369 6e6f >tmlq-utq.U.zicon< 0414080 6d49 6761 7165 282f 0855 0000 0000 0000 >Imageq/(U.......< 0414096 7c13 3071 5528 4f09 5346 492e 616d 6567 >.|q0(U.OFS.Image< 0414112 3171 4f63 5346 492e 616d 6567 490a 616d >q1cOFS.Image.Ima< 0414128 6567 710a 7432 3371 7174 5134 1255 5f5f >ge.q2tq3tq4QU.__< 0414144 6361 705f 7265 696d 7373 6f69 736e 5f5f >ac_permissions__< 0414160 3571 5529 5f09 5f70 6573 6972 6c61 3671 >q5)U._p_serialq6< 0414176 0855 3003 6196 3bbc cc84 3771 0a55 5f5f >U..0.a.;..q7U.__< 0414192 6f6d 7564 656c 5f5f 3871 1955 372a 6233 >module__q8U.*73b< 0414208 7169 4170 3249 4451 3261 4b69 6950 7674 >iqpAI2QDa2iKPitv< 0414224 3735 3d67 713d 7539 7174 743a 4e2e 002e >57g==q9utq:t.N..< 0414240 0000 0000 1300 0378 4e36 9e89 e3b3 003b >......x.6N....;.< . . . 0416384 2e74 717d 2e04 0000 0000 0000 7e13 3603 >t.}q.........~.6< 0416400 894e b39e 3be3 0000 0000 0000 0000 0000 >N....;..........< 0416416 0000 0500 67dc 0000 0000 0000 0000 9600 >.....g..........< 0416432 2828 0f55 435a 616c 7373 7365 4d2e 7465 >((U.ZClasses.Met< 0416448 6f68 7164 5501 5a12 6c43 7361 4d73 7465 >hodq.U.ZClassMet< 0416464 6f68 7364 6853 6565 7174 7402 0371 744e >hodsSheetq.tq.Nt< 0416480 7d2e 0471 5528 5f03 646d 0571 717d 5506 >.}q.(U._mdq.}q.U< 0416496 5f08 626f 656a 7463 7173 2807 717d 2808 >._objectsq.(}q.(< 0416512 0955 656d 6174 745f 7079 7165 5509 440b >U.meta_typeq.U.D< 0416528 4d54 204c 654d 6874 646f 0a71 0255 6469 >TML Methodq.U.id< 0416544 0b71 0b55 6e69 6564 5f78 7468 6c6d 7120 >q.U.index_html q< 0416560 750c 5574 6902 7164 550d 6d07 7465 6f68 >.utU.idq.U.metho< 0416576 7364 0e71 2e75 0000 0000 0000 df7e 3603 >dsq.u.......~..6<
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
participants (6)
-
Alexander Chelnokov -
Bill Welch -
Chris McDonough -
Chris Withers -
seb bacon -
Stefan H. Holek