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

[Christian Mollekopf]

On Sat, Oct 11, 2014, at 11:46 PM, David Faure wrote:
> 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?
> 

That's done in the ItemSync, and it should already do that. That's why I
don't know how you can end up in a state like this.

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

Indeed. Akonadiconsole, right-click, Clear Akonadi Cache

> > > ====
> > > 
> > > "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?
> 
 I guess because it's not just a cache ;-) It's a writable "cache" that
 can hold data that is stored nowhere else until the backend manages to
 replay it to the server.
_______________________________________________
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/