Hi Patrick, On 24.09.2014, at 17:33, Patrick Ohly <patrick.o...@intel.com> wrote:
> Let me pick your brain for a second... :-) It has gotten a bit rusty as far as sync is concerned. But I'll try :-) > When SyncEvolution runs a local sync (i.e. both client and server are > provided by SyncEvolution) and the sync gets aborted (= STEPCMD_ABORT is > passed to SessionStep()), I noticed that the next sync starts again as > if nothing happened. > > For example, aborting a normal two-way sync and then syncing again does > another normal sync using the same sync anchors because the datastores's > SaveAdminData has never been called during the aborted sync. What I *remember* (=not verified by looking at the code recently) is that the engine tries to find out if "anything has happened" already when the sync is aborted. If so, it would save state. Otherwise, it would just stop and next sync would start "as if nothing happened" (because it thinks in fact nothing of importance *has* happened, and avoid the relatively expensive process of saving state). > The result is that the server can end up adding the same items twice, > once during the aborted sync and again during the next one. This causes > duplicates, because the client side has no means of detecting the > duplicate. Did you actually see such problems happeing or do you just anticipate them because they *would* occur if the engine *did* abort without saving state in all cases? Now I could not resist looking at the code - two of these "early abort" checks are in TSyncAgent::NextMessage(), look for "happened" in the comments, but these only apply to early suspends, not abort. I guess another relevant check is in TLocalEngineDS::engAbortDataStoreSync(), look for "preventResuming". I don't have the complete picture however from just this quick look up... > How is this case supposed to be handled? Is SyncEvolution doing > something wrong in its change or meta data handling? The only thing I could imagine going wrong would be not to continue calling SessionStep() after the STEPCMD_ABORT until SessionStep() actually signals session done, because it might take another step to completely clean up the session, which is needed to make all datastores call saveAdminData. Best Regards, Lukas
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
