Can’t CopyTo a PST

We recently had a customer who was copying messages around using CopyTo. They found that for certain messages, if the target message store was a PST, they’d get MAPI_E_NO_ACCESS (0x80070005). They saw this for the same messages every time, when other messages would copy to the same PST just fine.

When I debugged the failure, I found the root of the problem was that the source message had an attachment with the property 0x67100003 set on it. The PST provider does not allow this property to be set on a messages in its store, so any attempt to set it returns the error MAPI_E_NO_ACCESS. When they did the CopyTo of the message properties, because PR_MESSAGE_ATTACHMENTS was not excluded, one of the side effects was that MAPI looped through the the attachments and copied them, using calls to CopyTo at the attachment level. These CopyTo calls did not use an exclusion array at all, so every property on the source attachments were copied to the destination. When CopyTo reached the property 0x67100003, the PST provider returned an error, which caused the attachment level CopyTo to fail, which in turn caused the customer’s CopyTo call to fail.

By the way, 0x67100003 isn’t the only property that causes this problem. In fact, most properties in the service provider defined non-transmittable range (0x6600-0x67FF) caused the same problem.

The fix we used was to add PR_MESSAGE_ATTACHMENTS to the exclusion list for CopyTo, then copy the attachments manually using OpenAttach, CreateAttach, and CopyTo, passing an exclusion array specifying that the non-transmittable properties should be excluded. Since this is the same logic CopyTo uses to copy attachments (without the exclusion array), doing the copy like this doesn’t have a performance hit.

Comments (2)

  1. Interesting…Which PST provider(s) was that with? I presume it was one of Microsoft’s, but Unicode/non-Unicode/version… Another more important question is why is that so, i.e. why would the [MS] PST provider refuse to copy such properties? At first glance (although there may be a good reason), this sounds like an arbitrary limitation; for instance this presumably can cause problem when archiving messages from another store (e.g. Exchange mailbox).

  2. This was with Outlook’s PST provider. I didn’t try it with Exchange’s provider. The props it rejected were used internally and allowing them to be set would cause problems. We never did figure out how the message files got the props set on them in the first place – the customer wasn’t able to tell me much about how/where they got the messages.

Skip to main content