4:59 a.m.
On Sun, 2012-02-26 at 11:17 +0100, Justus-bulk(a)Piater.name wrote:
Hi,
A few days ago, an addressbook sync failed with the following error
(which I anonymized) on the N9:
[INFO] addressbook: updating "ThisFirstName ThisLastName"
[ERROR] stderr: QTrackerDirectSyncResult: QSparqlError(4,
"GDBus.Error:org.freedesktop.Tracker1.SparqlError.Constraint: Unable to insert
multiple values for subject `urn:uuid:15cdee1e-e3f1-dcef-59fc-2e734089ffc0' and single
valued property `nao:prefLabel' (old_value: 'BUSINESS', new value:
'Business')", 1) "
followed by lots more output, included below. This appeared to come
totally out of the blue; I have no idea what I did differently than
before (no unusual addressbook edits, no N9 software updates, no related
laptop updates AFAICT, though I closely track Debian testing). Working
around this involved removing all category tags from all of my
addressbook records (which was OK because I need a better scheme
anyway), but this is of course no long-term solution.
You should report that bug to Nokia and/or the QtContacts-Tracker
developers. That sounds very much like an internal error in the contact
storage, related to the way how the QtContact API is mapped to Sparql
updates by QtContacts-Tracker.
During my attempts to get back into a syncable state with
"syncevolution
--sync refresh-from-server", the system irritated me by stating
[INFO] addressbook: resuming first time sync from server
even though I meant to restart the refresh from scratch. This might be
just the message though; the sync may have done the right thing.
It probably did, but you are right, there client keeps some state
information and thus recognizes that it is not starting quite from
scratch.
Or, more accurately, attempted to do the right thing, because the
Sparql
error persisted for all records bearing category tags, until I removed
them all.
SyncEvolution deletes all contacts before importing them again in a
refresh-from-server sync. It does not delete categories. I'm not sure
whether it should.
Afterwards my calendars refused to sync (thanks to
preventSlowSync=1):
[ERROR] sync: aborted on behalf of user (local, status 20017)
[INFO] calendar: starting first time sync, two-way
[INFO] calendar: first time sync done unsuccessfully
[ERROR] calendar: unexpected slow sync (local, status 22000)
[ERROR] error code from Synthesis engine local, status 20048
even though, so I would think, calendar sync status should be totally
unrelated to addressbook sync status.
Your expectation is correct. To debug this further I would need the log
file of the last sync which involved the calendar and which failed, and
the log with the unexpected slow sync.
Perhaps the client treated the error in the contact backend as "fatal
error in the system" and aborted the entire sync session instead of
completing the rest of the sync for the calendar. I don't have a test
for this. Hmm, perhaps I should write one...
--
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.