On Wed, 2012-02-08 at 20:27 +0100, Tino Keitel wrote: > Hi, > > I recently get an error when trying to sync the calendar with a remote > syncevolution (1.2.1, now 1.2.2). > > This is the error on the command line: [...] > The HTML log contains a lot of there errors: > > RemoteID=1142 [--][++] [->end] [->enclosing] > > [2012-02-08 20:10:18.702] add item operation received > [2012-02-08 20:10:18.702] startDataWrite called, status=0 > [2012-02-08 20:10:18.702] TStdLogicDS::logicProcessRemoteItem > starting, SyncOp=add, RemoteID='1142', LocalID='' > [2012-02-08 20:10:18.702] Executing Script 'beforewritescript' > [2012-02-08 20:10:18.702] adding "XXX" > [2012-02-08 20:10:18.710] InsertItemAsKey res=409 > [2012-02-08 20:10:18.710] cannot create record in database > (sta=409) > [2012-02-08 20:10:18.710] Database Error --> SyncML status 409 > [2012-02-08 20:10:18.710] - Operation add failed with SyncML > status=409 > > –[2012-02-08 20:10:18.710] End of 'Process_Item' [->top] [->enclosing]
Is that from the local side? You are using Evolution there, right? Is the server side using the file backend? In such a combination it is possible that the server ends up storing two independent items with the same UID, because the file backend is oblivious of the iCalendar 2.0 UID/RECURRENCE-ID semantic. When that happens, the server asks the client to store an item that the client already has, which the client can detect based on the UID/RECURRENCE-ID. The client then refuses to add that item again with the 409 status to the engine. One the server side the engine in SyncEvolution 1.2.2 was able to handle that, but not on the client side. Support for that was added later, and I have suggested further refinements to it - see the '409 "item merged" in client + multiple sync cycles in a single session' mail thread. I haven't investigated what exactly happens in 1.2.2 when such a problem occurs. The only workaround that I can recommend in that release is to avoid the file backend as storage on the server side. That's also better with later release (less traffic, lower risk of sending duplicates to clients which do not themselves detect them). I know that the file backend is attractive for the server side because of its simplicity, but in this case it is simply a bit too simple. Patches to teach the file backend enough of iCalendar 2.0 to avoid the issue would be welcome. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
