On Wed, 2013-02-13 at 20:08 +0100, Christof Schulze wrote: > Since recently I am getting this error message when I trigger a sync > between my nokia e51 phone and a webdav backend that is also used by > akonadi. > > Warning: Failed with status code=412, statistics are incomplete!! > > the logdire contains two xml snippets that are invalid xml because they > are incomplete. However I cannot see a reason for that: [...]
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. > The log contains: > –[2013-02-13 18:26:16.257] 'processStatus' - Processing incoming Status [--] > [++] [->end] [->enclosing] > [2013-02-13 18:26:16.257] Started processing Command 'Status' (incoming > MsgID=3, CmdID=3) > [2013-02-13 18:26:16.257] WARNING: RECEIVED NON-OK STATUS 412 for command > 'Delete' (outgoing MsgID=2, CmdID=6) > [2013-02-13 18:26:16.257] - SourceRef (localID) = '#1' > [2013-02-13 18:26:16.257] Found matching command 'Delete' for Status > [2013-02-13 18:26:16.257] translated tempLocalID='#1' back to real > localID='02f1e4dc-5b20-4728-b1be-708425e33689.vcf' > [2013-02-13 18:26:16.258] dsConfirmItemOp completed, syncop=delete, > localID='02f1e4dc-5b20-4728-b1be-708425e33689.vcf', remoteID='', FAILURE, > errorstatus=412 > > My guess is, that this means that the item already was deleted in the > webdav (by akonadi) and at the same time deleted in the phone. > Then a sync was triggered. 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? > What can I do to remediate the situation? 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
