Re: [openchange]OpenChange 1.0 BORG Released!

I found the real reason, which I think is a bug introduced in
/branches/sogo/libmapi/IMAPIProp.c  <at>  2798, but which only surfaces if
MAPI_PROPS_SKIP_NAMEDID_CHECK is  not used.

Basically, if any named properties are used and skipping is not in
effect, then the "named" boolean is set. This is used to unwind the
modifications made to the passed in tag array. However, 2798 copies
the modified tag array, so it can be copied into the output array, and
this copy does not have the unwind logic applied to it. The caller
cannot recover from this since the name translation array (nameid) is
internal to this function.

A change like the following fixes this for me:

diff -r -U5 openchange-1.0-BORG/libmapi/IMAPIProp.c
fixed-openchange-1.0-BORG/libmapi/IMAPIProp.c
--- openchange-1.0-BORG/libmapi/IMAPIProp.c     2012-03-13
16:58:28.000000000 +0000
+++ fixed-openchange-1.0-BORG/libmapi/IMAPIProp.c       2012-03-17
16:11:12.831315177 +0000
 <at>  <at>  -156,10 +156,11  <at>  <at> 
        /* Read the SPropValue array from data blob.
           fixme: replace the memory context by the object one.
        */
        if (named == true) {
                mapi_nameid_unmap_SPropTagArray(nameid, SPropTagArray);
+               mapi_nameid_unmap_SPropTagArray(nameid, &properties);
        }
        talloc_free(nameid);

        mapistatus = emsmdb_get_SPropValue((TALLOC_CTX *)session,

&mapi_response->mapi_repl->u.mapi_GetProps.prop_data,

Of course, the other option is for callers to manage the named
property logic themselves, which is presumably why nobody else has
seen this.

Thanks, Shaheed