corrupted turba photos

Basically syncing contacts works fine in both directions. Co

Thu, 17 Jun 2010 12:15:11 +0000

Basically syncing contacts works fine in both directions. Contact photos get synced from the phone to Turba, but unfortunately they won't get synced back when modifying contacts in Turba. The result is, that contact photos are deleted on the phone and remain in Turba, regardless of any further syncs. /tmp/sync/data.txt lists the photo data in both sections "received from backend" and "converted for client": BEGIN:VCARD VERSION:2.1 NICKNAME: BDAY: PHOTO;ENCODING=b;TYPE=JPEG:w7/DmMO/w6AAEEpGSUYAAQEBAHoAegAAw7/DmwBDAAg... /tmp/sync/log.txt show nothing out of the ordinary: DEBUG:? Sending 1 server changes for client URI contacts DEBUG:? Sending replace from server: 20100221132611.33961m958i82mulc@mydomain.com DEBUG:? Sending to client DEBUG:? Return message completed About my environment: Horde 3.3.6 (stable), Turba 2.3.3, running with https Samsung OmniaLite GT-B7300, Windows Mobile 6.5, Synthesis SyncML Client STD 3.0.2.24 After doing a lot of tests together with the Synthesis crew they sent me the following explanation: 1) The Horde devInf is wrong. The correct type name is text/vcard, as sent with the items (which have the correct type). But the devInf shows text/directory, which is not correct. (our client ignores that, this is not the main reason for the problem) 2) We decoded the sent photo information. All the sent photos are completely corrupted and can't be displayed therefore. It looks like a wrong conversion from ANSI to UTF-8, e.g. the type is something like JFIF (not JPEG). So the server sends complete garbage within the photo field. A real JPG starts with: FF D8 DD E0 00 10 4A What we get is: C3 BF C3 98 C3 BF C3 A0 00 10 4A The starting C3 BF is simply FF in UTF-8.

I finally found the reason for this behaviour and managed to

Wed, 13 Oct 2010 21:31:28 +0000

I finally found the reason for this behaviour and managed to implement a hack for solving it. The reasing is, that all turba data is encoded utf-8 in the function tovCard() in lib/Driver.php. Photo and logo data should not be encoded, therefore I added the following code in line 1280 before the data gets base64 encoded: $val = utf8_decode($val); I know this is just a quick hack, but it works. Hopefully someday someone will implement a better solution. Since I'm not familiar with the Horde developement process (CVS, GIT, etc), maybe someone could add this line of code to the source, thanks.

Changes have been made in CVS for this ticket: Fix photo co

Thu, 21 Oct 2010 16:45:37 +0000

Changes have been made in CVS for this ticket: Fix photo corruption when exporting to vCard 3.0 (Bug #9100). http://cvs.horde.org/diff.php/turba/docs/CHANGES?rt=horde&r1=1.181.2.257&r2=1.181.2.258&ty=u http://cvs.horde.org/diff.php/turba/lib/Driver.php?rt=horde&r1=1.57.2.98&r2=1.57.2.99&ty=u

This doesn't make much sense to me, because we only do chars

Thu, 21 Oct 2010 16:46:34 +0000

This doesn't make much sense to me, because we only do charset conversion if exporting to vCard 3.0. Your example is vCard 2.1 though. Try what I committed anyway and see if it fixes the corruption for you.

> 1) The Horde devInf is wrong. The correct type name is tex

Thu, 21 Oct 2010 16:47:24 +0000

> 1) The Horde devInf is wrong. The correct type name is text/vcard, > as sent with the items (which have the correct type). But the > devInf shows text/directory, which is not correct. > (our client ignores that, this is not the main reason for the problem) Without access to the sync logs myself, I can't say anything about that.

> This doesn't make much sense to me, because we only do cha

Thu, 21 Oct 2010 17:19:04 +0000

> This doesn't make much sense to me, because we only do charset > conversion if exporting to vCard 3.0. Your example is vCard 2.1 > though. Try what I committed anyway and see if it fixes the > corruption for you. It doesn't make sense to me either. I tried your fix, but it did not work, because (as mentioned correctly) my vCard is 2.1, so this part of the code won't be executed anyways. However, the issue is definitely utf8 related, since my hack (see below) works. Maybe data gets utf8-ed at some point before? As far as I found out image data is not utf8 in the database.

>> 1) The Horde devInf is wrong. The correct type name is te

Thu, 21 Oct 2010 17:21:51 +0000

>> 1) The Horde devInf is wrong. The correct type name is text/vcard, >> as sent with the items (which have the correct type). But the >> devInf shows text/directory, which is not correct. >> (our client ignores that, this is not the main reason for the problem) > > Without access to the sync logs myself, I can't say anything about that. I searched all horde sync logs and did not find any occurence of text/directory anywhere. Don't know how/where the guys from systhesis found this. However, it does not seem to cause this issue.

Please read http://wiki.horde.org/SyncMLProblemReport and fo

Wed, 30 Mar 2011 11:00:14 +0000

Please read http://wiki.horde.org/SyncMLProblemReport and follow the steps to generate complete SyncML debugging information.

Problem is fixed with Horde H4, tested with Turba 3.0.7. Wit

Tue, 30 Aug 2011 16:25:33 +0000

Problem is fixed with Horde H4, tested with Turba 3.0.7. With a quick check I found out, that the following lines in /turba/lib/Driver.php were removed: if ($version != '2.1') { $val = String::convertCharset($val, NLS::getCharset(), 'utf-8'); }