Hello Patrick, On Sep 7, 2011, at 14:53 , Patrick Ohly wrote:
> SyncEvolution's ActiveSync backend uses the sync anchor passed into > StartDataRead() for change tracking. The new anchor is created in > EndDataWrite(). The sync anchor is the ActiveSync "sync key", created > and updated by the ActiveSync server as changes are made to the data. > > I now have the following situation: because of a misconfiguration of the > client, it attempts to start a sync with an invalid sync key. The > ActiveSync server rejects it in StartDataRead(), which returns a 10500 > error code. > > [...] > > The error causes apiReadSyncSet() to bail out, without ever calling > EndDataWrite() in that session. Because the backend never gets the > chance to reset the sync anchor, the next sessions just do the same > thing again and again. Ok, I see the problem. StartDataRead() is unfortunately too late in the process of the SyncML protocol to convert the sync into a slow sync in the same session (latest point where this is possible is when handling the Alert from the server, which is before starting to read from the DB). But what we could do is allow StartDataRead to return 508 error code to have the engine reset sync anchors before bailing out, such that the next session would become a slow sync. Would that solve the problem? Best Regards, Lukas Lukas Zeller, plan44.ch [email protected] - www.plan44.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
