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

[Daniel G. <dg...@su...>]

On Tuesday 12 February 2008, Michael Bell wrote:
> >>> 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?
>
> The problem is that the SyncML plugin detects the necessary slowsync
> during the get_changeinfo call or better during the processing of the
> get_changeinfo request. There is no function where we determine the type
> of synchronization.
>
> @Daniel: is this correct?

Slow Syncing gets triggered like this:

#1 Group was locked -> All Object Engines get triggered for a slow-sync.
#2 Plugin triggers slow-sync: anchor mismatch (which should be the case if it 
got synced in meanwhile with another environment)


In this case 2nd should appear. The Object Engine(s) should get set to perform 
a Slow Sync. Then it's  up to the plugin in the get_changes sink function to 
check if a slowsync got requested by the Object Engine or not.

If not all plugins perform a plugin there are two possibilities what went 
wrong:

#1 Buggy Plugin which doesn't check for SlowSync carefully in the 
get_changes() function (in this case the file-sync plugin... but it checks 
correctly the sink for slowsync in the get_changes() function)

#2 OpenSync doesn't flag the correct Object Engine to perform a slow-sync. So 
the Sink Engine isn't flagged and the plugin will not perform a slow-sync.  
(VEEEERY LIKELY since we did some changes with the sinks!!!!!!!!!!!!!!!! 
Michael already mentioned this in another mail.)