Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Simon J. <si...@jo...>]

Michael Bell <mic...@cm...> writes:

> Simon Josefsson schrieb:
>
>> Is it the correct decision to do a full sync then?  I assume the sync
>> with iSync incremented a counter somewhere, which would trigger a full
>> sync in opensync.  Confirming this would be one step forward in my
>> understanding.
>
> I think I have to define some terms for SyncML clients like a phone.
>
> We only know normal (TWO-WAY-SYNC) sync and slow sync (SLOW-SYNC) in
> terms of SyncML. The same is correct for OpenSync. There is no
> fullsync which is only a slow sync.

Thanks for explaining.

>> I confirmed that it says 201 when i sync after running isync.  This
>> results in dupe entries added to the file-sync, see output last in this
>> message.
>
> This means OpenSync performs a SLOW-SYNC. Internally the server (our
> SyncML plugin) detects that a SLOW-SYNc is requested and sets the sink
> (some kind of a datastore of OpenSync) into SLOW-SYNC mode. This means
> that OpenSync performs a SLOW-SYNC with your phone.

Right.

>> Output from 1) and 2) respectively below.  Note how entries are
>> transferred FROM the file-sync only in case 2).  The problem in 1) seems
>> to be that msynctool doesn't request a slow-sync from ALL devices when
>> one of them does a full sync.
>
> Perhaps we need advice from a more senior project member. Is this an
> OpenSync or a msyntool bug? The SyncML plugin signals slow sync via
> the sink.

Could it be a timing problem?  I.e., that syncml signals a slow-sync
when the file-sync plugin has already started doing a two-way-sync?

It would help if msynctool would print out when some plugin requested a
slow sync..  My opensync-fu is to weak to come up with a patch though.

/Simon