Re: Resolved the problem with contacts including binary data

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/