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

[Michael B. <mic...@cm...>]

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.

>> OpenSync does not know anything about iSync. So if you start OpenSync
>> it think it starts a normal Two-Way Sync. Now the SyncML part of the
>> story begins. The DS client (your phone) sends a Slow-Sync or a
>> Two-Way Sync with a LAST and a NEXT anchor. If your phone sends
>> Slow-Sync request then the plugin immediately switch the sink to
>> Slow-Sync mode. If the plugin receives a wrong LAST anchor then
>> Slow-Sync is activated too. So the important question is, does
>> OpenSync really makes a Slow-Sync? The mode switch is not displayed at
>> the normal console.
>>
>> If you enabled traces then grep the logfiles for the string
>> smlDsSessionSendAlert. The second parameter in the parenthesis is the
>> alert type. The numbers are compliant with the OMA DS spec (200 - 
>> TWO-WAY-SYNC, 201 - SLOW-SYNC.
> 
> 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.

>>> What happens is that opensync retrieves all entries from the phone, and
>>> adds them to the local 'file-sync' sink.  The id's are the same, so to
>>> avoid overwriting the file, it adds '-new' to each filename.  If I
>>> perform this several times, I can get 'X-new-new-new' or even worse.
>> This is what I'm observing too but I think this is a logical problem
>> because the merger should compare the entries and detect the
>> duplicates. BUT: I only understand the syncml code. I'm a normal user
>> if we are discussing about non-syncml stuff :(
> 
> The problem is that msynctool slow-sync appear to work in two different
> ways:
> 
> 1) normal slow-sync, triggered by --slow-sync or initial run.  This
> appears to pull in all entries from all devices, i.e. both from the
> file-sync and syncml-obex-client stores.  the entries are then merged,
> and the result is pushed back to each backend.  This works fine.
> 
> 2) slow-sync after running isync, likely triggered by the phone rather
> than opensync?  This seems to do a fast-sync against the file-sync (no
> entries are transferred from file-sync) but a slow-sync against
> syncml-obex-client.  This leads to pulling in duplicate entries into
> file-sync, because none of its entries were pulled in for merge
> handling.

This is cleanly a bug of OpenSync and has nothing to do with the SyncML 
layer or with iSync. The same happens if OpenSync thinks a sync was 
successful and the phone thinks the sync fails (e.g. if the last package 
from the server is lost).

> 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.

Best regards

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de