Hmmm... that code is really interesting:
int objlen = 65536;
sync_object_type objtype;
filename = g_strdup_printf("telecom/pb/luid/%s.vcf", luid);
objlen = 10240;
i wonder why objlen is assigned twice. i guess someone must have had a
reason to limit the objlen. Does anyone know why (Not that we break
something else by removing this limit)?
On Tue, 2004-11-30 at 23:40 +0100, Jonas Birmà wrote:
> Hi,
>
> The attached patch resolves the problem with not syncing contacts which
> included binary data, for example voice commands or pictures. Try it out
> and of course backup the phonebook first. Apply with (in multisync
> topdir):
>
> % patch -p0 < voice-contact.patch
>
> Technical details:
>
> It was quite hard to find but the problem was caused by this
> (irmc_obex.c:get_client_done):
>
> if (ud->databuf && ud->databuflen && *(ud->databuflen) >= body_len) {
> // Copy received data to buffer
> ...
> }
> ...
>
> which is not wrong and should of course be checked. What actually
> happened was that a contact containing voice data is (almost everytime)
> larger than *(ud->databuflen).
>
> What I did (as a quick fix) was to remove this line in irmc_sync.c
>
> //objlen = 10240;
> if ((ret=irmc_obex_get(conn->obexhandle, filename, objdata, &objlen))<0)
> { ... }
>
> not entirely solving the problem since it would ignore contacts larger
> than 65536. The data is BASE64 coded and some warnings occurs with evo2
> plugin at least, since it is not handled by evolution.
>
> /Jonas
--
Armin Bauer <[EMAIL PROTECTED]>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Multisync-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/multisync-users
