Re: [Opensync-users] Synce plugin in FC4

[Armin B. <arm...@de...>]

Hi Remy,

are the vcards you are synchronizing of type 3.0 or 2.1?

R=C3=A9my Amouroux wrote:
> Hello
>=20
> I finally compiled the synce plugin using a fresh checkout from cvs and=

> used it  for synchronisation with evo2 and the file plugin
>=20
> I first tried to use a pair synce-evo2.
>=20
> Unfortunately, I had a segmentation fault and it was impossible to
> understand which one had a problem.
>=20
> So, I put in place a pair synce-file and did my first synchronisation.
>=20
> $ msynctool --showgroup ipaqFile
> Groupname: ipaqFile
> Member 1: synce-plugin
> Member 2: file-sync
>=20
>=20
> It worked perfectly well and I had a folder full of files containing
> each either a VCAL or a VCALENDAR. And it looks like they had all one
> probl=C3=A8me: wherever the value of the field contained a non ascii
> character (like an accent letter), the value was cut.
> For instance, instead of=20
>    SUMMARY:Appeler caisse d'=C3=A9pargne
> I have
>    SUMMARY:Appeler caisse d'
>=20
> I naturally did some modifications (manually) on a fem items on my Ipaq=

> and tried to synch again.
>=20
> msynctool started to ask questions about conflicts with the following
> trace before asking the question:
>=20
> Conflict for Mapping 0x879f460:
>=20
> Entry 1:
> UID: 02002e1e
> File: 02002e1e
> Size: 211
>=20
> Entry 2:
> UID: 02002e1e
> <?xml version=3D"1.0"?>
> <contact>
>   <UnknownNode>
>     <NodeName>PRODID</NodeName>
>     <Content>-//SYNCE RRA//NONSGML Version 1//EN</Content>
>   </UnknownNode>
>   <Telephone>
>     <Content>+33 820 04 20 20</Content>
>     <Type>WORK</Type>
>     <Type>VOICE</Type>
>     <Type>PREF</Type>
>   </Telephone>
>   <Telephone>
>     <Content>+33 800 08 24 24</Content>
>     <Type>WORK</Type>
>     <Type>VOICE</Type>
>   </Telephone>
>   <FullName>
>     <Content>Achard, Sandrine</Content>
>   </FullName>
>   <Name>
>     <LastName>Achard</LastName>
>     <FirstName>Sandrine</FirstName>
>   </Name>
>   <Organization>
>     <Name>Total Gaz</Name>
>   </Organization>
> </contact>
>=20
> Which entry do you want to use (D for Duplication)?
>=20
> Each time I answered "2" (which is wrong in my case, since member 2 is
> the file plugin and no changes were done in that part) but it looks lik=
e
> I had a conflict with each entry, thus I simply stopped the sync.
>=20
> Any idea about what I should do (apart debugging the stuff myself) ?=20

i think there are 3 separate problems here:

1. the segfault: this should not happen of course. a trace from opensync
and a backtrace with gdb should help to find the bug.

2. wrong handling of non ascii characters: this is a know bug. the cause
is that there is no way currently to specify the encoding of a vcard. so
the encoding is not changed and opensync cannot handle the input since
it is not utf8. this will be fixed in one of the next versions.

3. conflicts: since your first sync failed, opensync will do a slow-sync
which means that it will load all objects from each side and compare
them again. the comparison obviously does not work correctly since it
raises a lot of conflicts. a trace of the synchronization that raises
these conflicts should help.

Armin

>=20
>=20
> Information about opensync and FC4.
>=20
> On Mon, 2005-10-03 at 23:17 +0200, Armin Bauer wrote:
>=20
>>R=C3=A9my Amouroux wrote:
>>
>>>Waiting for an answer from the synce-devel maintainer, I wanted to go
>>>further compiling the synce plugin.
>=20
>=20
> He answered quite quickly: opensync is in his todolist and the opensync=

> rpms should appear in Fedora extra in a matter of days.
>=20
> regards
>=20
> 	RemyA