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

[Daniel Vratil]

On Sunday 12 of October 2014 13:44:18 Christian Mollekopf wrote:
> 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.

In theory. In practice this has never been enforced, so I'm afraid doing that 
now might break some stuff. But I totally agree that we should do that in 
Frameworks. I'm only afraid that a unique index collectionId-RemoteId might be 
rather expensive because of the amount of items we have. Also I'm unsure how 
the index would behave with an empty RID, as we allow multiple items with 
empty RID within the same collection. I guess this is the main reason it has 
never been enforced. And manual check would be far too expensive.

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

I have couple these emails too. I guess in certain cases, like interrupted 
ItemSync (crash, network error, whatever) we can end up in inconsistent state. 
Theoretically this should be protected by a transaction, unfortunately doing 
ItemSync on large amounts of items within single database transaction degrades 
the performance massively, so we split into multiple transaction.

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

 ^ This is most probably what left you with so many "unreferenced files" - the 
"Clear Akonadi Cache" action (or simply just the DELETE query) will only drop 
items from database, but won't clean up the filesystem

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

Yep - theoretically if things go South you might still be able to recover 
emails from lost+found you have composed but Akonadi failed to sync them to 
resource and then somehow stuff broke and you ended up with broken database 
:-) I guess it's like lost+found on your EXT filesystem - it's there taking 
space, but you consider the file lost rather than going there and trying to 
find it :D


Dan

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

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141013/38143c88/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/