I think this problem is actually easier to solve in the common case than requring that people run a conversion script. The ZGlobals data structure is a cache, and can be blown away and recreated indiscriminately. It's recreated whenever a Product is added or removed, and Zope already does this as a matter of course if anything about the data structure is goofy.
I think the problem Sidnei has run into isn't so much that the BTree module can't be imported, it's instead that the Persistence.PersistentMapping module redefines PersistentMapping in order to do something I don't quite understand, and the redefinition is what appears to be causing the AttributeError, 'data' to appear. If it's not used, everything works fine. Here's the module: import Persistence import persistent from persistent.mapping import PersistentMapping if Persistence.Persistent is not persistent.Persistent: class PersistentMapping(Persistence.Persistent, PersistentMapping): """Legacy persistent mapping class This class mixes in ExtensionClass Base if it is present. Unless you actually want ExtensionClass semantics, use persistent.mapping.PersistentMapping instead. """ If you comment out the "if" clause and everything underneath of it, make a dummy BTree.py module with the following and put in in the software home: from Globals import Persistent class BTree(Persistent): pass ... and restart Zope with an "old" filestorage file, all is well: [EMAIL PROTECTED] zopemafia.org]$ bin/zopectl-trunk debug Starting debugger (the name "app" is bound to the top-level Zope object) >>> app.objectIds() ['acl_users', 'Control_Panel', 'temp_folder', 'browser_id_manager', 'session_data_manager', 'error_log', 'standard_error_message', 'standard_html_footer', 'standard_html_header', 'standard_template.pt', 'vhm', 'tacoma.bridge.jpg', 'tacoma.bridge1.jpg', 'index_html_orig', 'index_html', 'misc', 'innomatch', 'newplone', 'New Folder', 'scratch'] >>> root = app._p_jar.root() >>> root {'Application': <OFS.Application.Application object at 0x41419cac>, 'ZGlobals': <BTrees._OOBTree.OOBTree object at 0x4185826c>} >>> type(root) <class 'persistent.mapping.PersistentMapping'> >>> I'm not sure what the redefinition is supposed to achieve? FWIW, I've sort of got plope.com (which implies Plone) working against the trunk, although some other unrelated problems still appear to exist. On Fri, 2003-12-12 at 10:41, Sidnei da Silva wrote: > | I think that is true. On the other hand, it was a bit of a surprise to > | find a BTree in ZGlobals. Maybe they're hiding somewhere else, too. > > At least, the script didn't found another one. It did found 7800 > objects total, of which one was a BTree (ZGlobals). > > Now, in 2.7 I get this output (starting zope via 'zopectl debug'): > > >>> app > <Application instance at 414c8c80> > >>> app._p_jar > <Connection at 414ac74c> > >>> app._p_jar.root() > {'Application': <Application instance at 414c8c80>, 'ZGlobals': > <OOBTree object at 0x414d1c60>, 'RefreshData': {'auto': {'CCHS': 1}, > 'products': {'Archetypes': {'dependent_products': ('CCHS',)}}}} > > Which looks sane to me. But if I copy the same Data.fs to another > instance with Zope HEAD, the "AttributeError: data" is there again. It > *seems* to me that the root PersistentMapping is not being unpickled > correctly. > > > /var/src/zope/head/lib/python/ZODB/ZApplication.py(32)__init__() > -> conn=db.open() > (Pdb) n > > /var/src/zope/head/lib/python/ZODB/ZApplication.py(33)__init__() > -> root=conn.root() > (Pdb) n > > /var/src/zope/head/lib/python/ZODB/ZApplication.py(34)__init__() > -> if not root.has_key(name): > (Pdb) print root > *** AttributeError: data > (Pdb) type(root) > <class 'Persistence.PersistentMapping.PersistentMapping'> > (Pdb) print conn.root() > *** AttributeError: data _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )