I've started to test SyncEvolution client <-> SyncEvolution server
automatically. The server is currently using the plain file backend and
thus cannot detect add<->add UID conflicts.
In the test of that aspect I noticed the following problem:
* client and server both have a new item with UID=foo
* client sends an Add UID=foo to the server, which accepts the new
item, leading to a duplication on the server
* in the same session, the server sends his version of the UID=foo
* the client's backend detects the duplicate and returns 409 to
Here's the detailed log:
* [2011-12-14 12:48:53.896] InsertItemAsKey res=409
* [2011-12-14 12:48:53.897] cannot create record in database
* [2011-12-14 12:48:53.898] Database Error --> SyncML status 409
* [2011-12-14 12:48:53.899] - Operation add failed with SyncML
–[2011-12-14 12:48:53.900] End of 'Process_Item' [->top] [->enclosing]
* [2011-12-14 12:48:53.901] processSyncOpItem: Error while processing
* [2011-12-14 12:48:53.902] Irregularity in execution of item,
[2011-12-14 12:48:53.903] 'issue' - issuing command,
Cmd=Status [--][++] [->end] [->enclosing]
* [2011-12-14 12:48:53.903] Command 'Status': is 1-th counted cmd,
cmdsize(+tags needed to end msg)=38, available=149687
* [2011-12-14 12:48:53.904] WARNING: Non-OK Status 409 returned to
From there on it all goes south ;-)
The next sync in my testing is an intentional slow sync. The server
still has the two items with the same UID, the client adds one, then
rejects the second => slow sync fails, test aborts.
Lukas, can you remind me how this was meant to work?
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.