[Kde-pim] Collections without remoteId abort imap sync

[Volker Krause]

On Monday 20 February 2012 23:50:48 David Faure wrote:
> 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?

If you would have lost a change notification, the change would be missing on 
the server entirely. In your case you have the change written on the server 
(folder exists), just the confirmation that this has happened is missing 
locally. So, the problem must have occurred after the whole change 
notification process I think.	

> > 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. 

Not exactly, that would just work. The ID you are seeing there is not the one 
of the collection, but the one of its parent. This uniqueness constraint 
(parent id + name) just means a folder name must be unique inside a given 
parent.

> Shouldn't CollectionSync detect exactly that case and turn it into an
> update?

It does exactly that for matching [R]IDs. Strictly speaking that's all the 
means I have to identify a collection. The problem is caused by the fact that 
the server additionally assumes the name to be unique inside a given hierarchy 
(which is the case with most backends, and usually the only sensible thing to 
show to a user), while CollectionSync does not. My proposal was to align that, 
which might have sounded slightly more complicated :)

The current behavior of CollectionSync would duplicate the folder to be on the 
safe side (annoying, but if your state is out of sync not entirely 
unreasonable as a fallback), but the Akonadi server doesn't allow that anymore 
(it did in the very beginning). If we make CollectionSync aware of this 
restriction, it could use the name as fallback identification.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120221/7679a4db/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/