The Wrapped PST and Unicode Paths

A customer just raised this issue with our Wrapped PST provider sample. They were trying to retrofit the sample to use Unicode paths to the NST and found that the CreateStoreEntryID routine was producing an invalid entry ID after they changed to to use a Unicode path. Through experimentation, they were able to produce a valid entry ID and wondered if I could document the necessary format. It turns out we use two different formats for the entry ID of a wrapped PST. One format is for ASCII paths and the other is for Unicode paths. Here they are, represented as structures:

 typedef struct             // short format

 {

  BYTE        rgbFlags[4];    // MAPI-defined flags

  MAPIUID     uid;        // PST provider MUID

  BYTE        bReserved;  // Reserved (must be zero)

  CHAR        szPath[1];  // Full path to store (ASCII)

 } EIDMS;

 // Unicode version of EIDMSW is an extension of EIDMS

 // and szPath is always NULL

 typedef struct             // Long format to support Unicode path and name

 {

  BYTE        rgbFlags[4];    // MAPI-defined flags

  MAPIUID     uid;        // PST provider MUID

  BYTE        bReserved;  // Reserved (must be zero)

  CHAR        szPath[1];  // ASCII path to store is always NULL

  WCHAR       wzPath[1];  // Full path to store (Unicode)

 } EIDMSW;

The net effect of the difference in these structures is there are two NULL bytes prior to a Unicode path. If you’re interpreting the entry ID, one way to determine how to interpret it would be to cast it as EIDMS first, then check if szPath[0] is NULL. If it is, you need to cast it as EIDMSW instead.