This project is read-only.

Reading Folder properties - part 2

Aug 5, 2011 at 5:28 PM

I guess I do need to re-ask my original question - does the property_bag contain every possible property?  Now

I am looking to get, for example, property 0x3601 (PR_FOLDER_TYPE) from my folder object.  pstsdk tells me

that it does not exist for any folder, even though I see it with Outlook Spy.  When I iterate all the possible properties,

I do not get very many.  I do have PR_DISPLAY_NAME and PR_CONTAINER_CLASS (for some), and also 0x3602 and

0x3603 (PR_CONTENT_COUNT and PR_CONTENT_UNREAD).   But where are the remaining properties?


Aug 5, 2011 at 5:48 PM

No, the property_bag contains only the properties which are physically stamped on the object.

The "real" MAPI implementation is a lot more complex. Some properties are "virtual" properties; which are either calculated out of thin air or based on other properties. They show up like any other property in something like Outlook Spy, but they don't "really exist". Still other properties have default values; if they are stamped on the folder then that value is used, if they're not stamped then the default is used. Sometimes the default is to "check parent folder".

PR_FOLDER_TYPE is an instance of the former. mspst32.dll proper calculates the folder type based on a special bit of the node id: if this bit is set, it's a search folder, otherwise, it's a normal folder. The root folder itself (FOLDER_ROOT) is special cased.

The fact that pstsdk currently doesn't duplicate all of this logic is more or less a limitation of the SDK. This logic should map to one off helper functions on the appropriate pst layer object (folder, message, etc). property_bag is a generic lower level object which only reads/writes physical properties; if you unwrap to that you should know what you're getting into.

Now, PR_FOLDER_TYPE is an interesting case: pstsdk is an object oriented library, MAPI (generally) is not. There are actually seperate object types for search folders and regular folders at the SDK level. So, the fact that you even have a "folder" object implies that that PR_FOLDER_TYPE is FOLDER_GENERIC. serach_folder objects are FOLDER_SEARCH. There are seperate iterators to get at each type at every level.

Aug 5, 2011 at 6:21 PM

Thank you for the explanation.  I remember this issue from when I was working with libpff, and I noticed that it would not give me PR_BODY_HTML in some cases, even though MAPI does

(since it just generates it on the fly from the text body).  I assume pstsdk will have the same issue.  I was hoping to use PR_FOLDER_TYPE to avoid picking up folders such as IPM_VIEWS but

I can do it using the presence or absence of certain properties, or just by the folder name.


Aug 5, 2011 at 6:26 PM

Ah. Yeah, PR_BODY_* is an entire different complex mess, it'll dynamically generic RTF, HTML, or PlainText depending on what is asked for, and there are a series of flag properties to indicate what bodies are currently stamped and "in sync" on the message.

The canonical example of these special properties is subject prefix on messages; obviously it'd be inefficent to store it twice, so the subject is just stored once and prefix/normalized/etc are generated on the fly. There is also some special bitmagic that goes on (it's documented, but weird), so subject prefix/etc is actaully one example of special properties that PSTSDK does generate for you (check message.h).

Anyway in MAPI, PR_FOLDER_TYPE really only helps you distinguish between regular folders and search folders, not other "special" folders.