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
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
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
[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
[2013-02-13 18:26:16.258] dsConfirmItemOp completed, syncop=delete,
localID='02f1e4dc-5b20-4728-b1be-708425e33689.vcf', remoteID='', FAILURE,
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.