Working with Folder Objects

Newly created folders have the following special characteristics:

• When created, the ACL of a new folder is set to the ACL of its parent folder plus the folder’s creator (the caller of IMAPIFolder::CreateFolder), which is added as an owner of the folder.
• Replication settings for public folders are set to the parent folder’s settings if they are not set explicitly on the child folder. Otherwise, use the replication settings of the information store.
• A directory store object is created when a public folder is created. That is, when you call CreateFolder on a public information store, the information store provider also creates an object for that folder in the directory. This object may be hidden to users by the address book provider unless the PR_PUBLISH_IN_ADDRESS_BOOK property is set.

Access Rights Needed for GetProps and SetProps

You can call IMAPIProp::GetProps if you have read-only access, and you need owner access to call IMAPIProp::SetProps. Certain replication properties require administrator’s rights to the site object in order to set them. For more information about accessing objects in the information store, see About Information Store Security.

SaveContentsSort

The IMAPIFolder::SaveContentsSort method is not implemented by the Microsoft Exchange Server information store provider and will return MAPI_E_NO_SUPPORT if called. Normally, calling this method stores the messages within a folder in a given sort order. In this case, Microsoft Exchange Server automatically caches indices on an LRU (least recently used) basis and automatically saving the sorted list to disk for future use. This makes calling SaveContentsSort unnecessary.

Notes on Folder Usage

• The IMAPIContainer::GetHierarchyTable method is not implemented by the Microsoft Exchange Server information store provider.
• You can use the CopyFolder method to copy or move any folders to other locations. The folder to be copied need not be a direct child folder of the providing object (the folder object for which the IMAPIFolder interface was returned).
• There is no limit to the length of folder names and comments. NULL (““) folder names are not supported.
• You can create and save messages in a public information store, but you cannot submit messages from a public information store. If you create a message in a public information store, you can have the message take on the nature of a move/copy message or a forwarded message. A move/copy message has properties as you have assigned them. Creating a message as a forwarded message assigns properties as if it had been sent to the public information store. The message receives a sender property (whoever dragged the message to the public folder) and a recipient property (which refers to the public folder itself).

Additional Folder Property Interfaces

These complex folder properties are objects and are accessed as such. You can open them like any other object, and an interface is returned.

Using Contents Tables

A contents table lists summary information about mail user or Distribution-List objects in address book containers, or about messages in folders. Address book providers implement contents tables for each of their containers. Both information store and remote transport providers implement contents tables for folders. For more information, see the MAPI Programmer’s Reference.

The following topics apply to the use of contents tables.

Sorting Limitations

The Microsoft Exchange Server information store provider supports sorting on the PR_NORMALIZED_SUBJECT and PR_SUBJECT_PREFIX properties, but not on the PR_SUBJECT property. Clients are expected to sort on the PR_NORMALIZED_SUBJECT property. For example, a call to IMAPITable::SortTable with PR_SUBJECT as the key fails on EMS_PRIVATE (and returns the error MAPI_E_TOO_COMPLEX), while the PST provider supports this call.

Truncation

In contents tables (returned with QueryRows), the Microsoft Exchange Server information store provider truncates both binary and text properties.