This is from a sync from a phone using webdav as storage backend. I believe the 412 came from the webserver it is a valid http error code. I use syncevolution to sync my phone to that storage and I also sync akonadi to that storage which is independent from syncevolution. i first synced all of the above then removed this contact from akonadi and I might have edited it on the phone at the same time. Then I triggered the sync that led to the 412. i war able to resolve the matter by manually creating a vcard with the expected name in the webdav, triggered a sync for a couple of times and the error was gone. Am I using syncevolution in an unintended way? viele Grüße Christof -- Verschickt vom Mobiltelefon, daher die Kurzsätze etwaige orthographischen Unzulänglichkeiten. -- Urspr. Mitt. -- Betreff: Re: [SyncEvolution] no more sync - Warning: Failed with status code=412, statistics are incomplete!! Von: Patrick Ohly <patrick.ohly(a)intel.com&gt; Datum: 14.02.2013 08:48 On Wed, 2013-02-13 at 20:08 +0100, Christof Schulze wrote: [...] That's not the root cause. The dump can be incomplete when processing the messages stops early. More interesting is the corresponding syncevolution-log.html. This is from a sync with the phone, so the phone reports 412? 412 is not an error code that the Synthesis engine recognizes. The phone should have sent 404 if it cannot find the item it is meant to delete. The question remains how the sync got into this state: if the phone had deleted the item, it should have told the server and then the server should not have issued the Delete request in the first place. The #1 as temporary local ID leads to a different hypothesis: the server assigned that ID when sending a new item to the phone, but it never got back the phone's ID for that item. Later, that item got deleted on the server, causing the server to send a Delete with the only ID it has, the #1, which the phone doesn't understand. So the key question becomes: when did 02f1e4dc-5b20-4728-b1be-708425e33689.vcf first appear in a log file, and was it sent successfully to the phone? You can try to hack the server's meta data. Grep the phone's sync config directory in ~/.config/syncevolution for 02f1e4dc-5b20-4728-b1be-708425e33689 and remove the entry about it from the .ini file where it is listed. That should cause the server to forget about the item in the next sync. The normal approach would be a slow or refresh sync. If the phone doesn't let you choose those, then you could force a slow sync on the server side by some more hackery (= removing sync anchors). -- 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.