I just tried to register on the Bug tracker to be able to file this,
but it won't let me log in. Can somebodykindly take a look please?
On 17 March 2012 16:29, Shaheed Haque <srha...@theiet.org> wrote:
> I found the real reason, which I think is a bug introduced in
> /branches/sogo/libmapi/IMAPIProp.c @ 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
> @@ -156,10 +156,11 @@
> /* 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
_______________________________________________
devel mailing list
devel@lists.openchange.org
http://mailman.openchange.org/listinfo/devel
