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>
Datum: 14.02.2013 08:48
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.