[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Collections without remoteId abort imap sync
From:       David Faure <faure () kde ! org>
Date:       2012-02-20 22:50:48
Message-ID: 11770760.uUyxjhVbTC () asterix ! site
[Download RAW message or body]

On Monday 20 February 2012 14:28:16 Volker Krause wrote:
> On Sunday 19 February 2012 11:08:17 David Faure wrote:
> > :1, :2, :3, :4, :5)" :  "Duplicate entry '960-trainings-old' for key
> 
> What likely happened here is you created a new folder locally (added to
> Akonadi with empty RID), the IMAP resource created it on the server and
> failed to update the RID locally to the correct IMAP path (I don't know yet
> why that would happen though). 

Yep, sounds likely. I guess it happened during a time when all the email 
moving made the resource very unresponsive, and the change got lost.
IIRC it's still possible to lose change notifications somehow, right?

> Another, less likely, scenario is a conflict
> of two clients creating the same folder simultaneously.

Nope, didn't happen.

> The above error is then triggered on the next collection tree sync. The
> collection on the server and the local one cannot be matched usin g their
> RID, as a result of which CollectionSync tries to create the missing one
> from the server locally (causing the name clash), at which point it aborts.
> CollectionSync would also remove local collections missing on the server,
> but there's an extra safety check to not do that for RID-less objects (as
> they haven't been written to the server yet, by the definition of the RID).
> So, that will not make it recover here.
> 
> One solution I can see is making the matching in CollectionSync slightly
> more clever for the "leftovers" (stuff that couldn't be matched by RID) and
> just update the RID accordingly when finding matching names among those.

This sounds a little bit too complicated for the problem I'm seeing. There 
should be no need to "iterate and find leftovers". The "INSERT" error comes 
from an insertion operation that fails because the item is already in the 
database with the same ID+name. Shouldn't CollectionSync detect exactly that 
case and turn it into an update?
Or am I saying nonsense here?

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]