The sequence, as far as I can tell, is: 1) POIFSFileSystem(stream) is called
2) POIFSFileSystem() is the first call, which sets the property table to be new PropertyTable() and root to be null. Nothing else of relevance to the current issue, until processProperties, with the directory as null 3)Inside processProperties, the first check for the parent, results it being set as getRoot(). 4)In getRoot(), since root is still null, it creates a root from the property table, so we can translate how _root got instantiated to: new DirectoryNode(new PropertyTable().getRoot(), this, null) in EntryNode (super of Directory Node) the property is assigned, which means it is equivalent to new PropertyTable().getRoot() 5) getStorageClsid() is equivalent to getProperty().getStorageClsid(), which means that it is equivalent to (new PropertyTable()).getRoot().getStorageClsid() 6) This can be substituted with (new RootProperty()).getStorageClsid() because root property is only ever assigned once in PropertyTable(). 7) in RootProperty, nothing overrides the determination of cls id, so, going through a bunch of supers, we get Property() as the one responsible for creating it. 8) since _raw_data is of type new byte[], the assignment to _storage_clsid is new ClassID(new byte[], some default offset). Since the byte array is empty, the stored class id is therefore all 0s. In other words, new POIFSFileSystem(stream).getRoot().getStorageClsid().toString() should always return a bunch of 0s. Note that there is a PropertyTable(start, blockList) that appears to generate better stuff, but that is a local variable in POIFSFileSystem(InputStream) perhaps the bug is that it should be assigned to the class variable instead? Jeff Wang diCarta, Inc. -----Original Message----- From: Daniel Noll [mailto:[EMAIL PROTECTED] Sent: Monday, March 20, 2006 7:46 PM To: POI Users List Subject: Re: getStorageClsid() Daniel Noll wrote: > I'm fairly certain this is a bug because I've traced the creation of the > properties in a debugger, and the root property does have the correct > ClassID. At some point in the POIFSFileSystem constructor, it is then > throwing away the class ID, but I can't see exactly where it's being > thrown to. A reasonable workaround seems to be adding this at the bottom of the (second) POIFSFileSystem constructor: getRoot().setStorageClsid(properties.getRoot().getStorageClsid()); This doesn't fix the underlying problem which is that the entire root is somehow being clobbered somewhere, but it does at least make the one method I do need to call work as expected. Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com.au/ Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
