But I can only reproduce this with the PortalSite object for now, I suspected SkinnableFolder would also exhibit this bug, but didn't. Further, I deleted any subobjects (all *_tool objects etc.) from the PortalSite object and the same happened.
I guess so. It must be something in the skinning machinery. My message board application, NeoBoard, has the same skinning machinery as CMF's to give it a skinned look with or without CMF. And it exhibits the same symptoms with getPhysicalPath() calls. That's why I had to create a new method that returns the relative path of an article object. The built-in catalog of a NeoBoard instance saves uids like the following: /a_1 # first article /a_1/a_1 # first reply to a_1 /a_1/a_2 # seond reply to a_1 /a_2 # second article But visiting an article like the following still duplicates entries in the board's built-in catalog: /Board/a_1 -> /a_1 /Board/Board/a_1 -> /Board/a_1 /Board/Board/Board/a_1 -> /Board/Board/a_1 ... I think removing **all** instances of the container's id when catalogging article objects should work. Currently, only the first instance is being removed. I just didn't think acquisition would wreak this much havoc when misused :-(
Ok, here's a workaround which should work: Add a normal folder (stock zope) named 'CMF' (or whatever your Portal Site object is called) as a subobject to the Portal Side object. This will prevent it from acquiring itself and causing this havoc.
That works! Thanks for the tip. Best Regards, Wankyu Choi --------------------------------------------------------------- Wankyu Choi CEO/President NeoQuest Communications, Inc. http://www.zoper.net http://www.neoboard.net ---------------------------------------------------------------