[Kde-pim] getting more info out of "NO Multiple merge candidates, aborting"

[David Faure]

On Saturday 11 October 2014 20:16:17 Christian Mollekopf wrote:
> The RID *must* always be unique per collection, everything else is a
> broken state, at least as far as the imap resource is concerned.
> 
> So this in fact should never happen and IMO we should enforce it in
> while creating/modifying items. I'm not sure we can though
> because it could be (not sure, daniel probably knows more), that some
> resources for some reason don't use the RID that way.

Well the code (which decides on a RID) could still make sure to never assign 
the same RID twice... Isn't that done in the imap resource?

> If that would be the case there is also nothing akonadictl fsck can do.

Unless it special-cases IMAP, of course.

> The fix is to remove all, and to then sync. This will download the
> correct data and your sync should be fine again.

By remove I assume you don't mean deleting from the GUI :-)

So, just removing all pim items for that collection from the DB with a SQL 
statement?

> > ====
> > 
> > "Moved 431978 unreferenced files to lost+found."

What's lost+found in this context btw?

If akonadi is just a cache, why didn't it just delete these files?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

_______________________________________________
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/