On Sa, 2011-09-10 at 12:32 +0200, Lukas Zeller wrote: > 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?
It is sub-optimal because it will be visible to users. Currently SyncEvolution doesn't automatically start a new sync. This will also break the automated testing, which will bail out with that error instead of doing a slow sync. As one way of dealing with the problem adding such a special error code is worthwhile. But perhaps there is a different way? For example, could the datastore API extended with a "verify anchor" call which is called soon enough to discard the anchor and fall back to a slow sync? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
