[Kde-pim] mixedmaildir resource LRCONFLICT

Volker Krause vkrause at kde.org
Thu Jul 19 18:54:48 BST 2012


On Tuesday 17 July 2012 10:06:40 David Faure wrote:
> Clicking on an old mail folder that uses the mixedmaildir resource, I see:
> [...]
> akonadi_mixedmaildir_resource_2(4471)/akonadiresource (maildir)
> RetrieveItemsJob::Private::storeListResult: Store fetch got 1718 items of
> which 0 are new and 1718 are changed and 0 need to be removed
> akonadi_mixedmaildir_resource_2(4471)/akonadiresource (maildir): "NO
> [LRCONFLICT] Resource tries to modify item with dirty payload, aborting
> STORE.
> 
> and then a popup says "the resource is broken".
> 
> How do I debug this further?

I don't really know the internals of the mixedmaildir resource, Kevin is your 
man there. But I can comment on what the LRCONFLICT means.

"LR" stands for local/remote, ie. there are local changes that hasn't been 
played back to the backend yet at the time the resource tries to update the 
local state to what it sees in its backend.

As many other things, this should never happen and is most likely damage of a 
problem that happened earlier. ResourceBase ensures that local changes are 
always replayed before loading new stuff from the backend.

The way this is implemented is the dirty flag that every item has. It's set on 
any modification from anyone but the owning resource, ie. any local change. 
The resource resets it after applying the change to its backend (using 
changeProcessed() usually).

Most likely scenarios for something like this include:
- code path in mixedmaildir not calling changeProcessed() (but rather e.g. 
taskDone()), ie. replaying (or intentionally ignoring a change) and then 
failing to reset the dirty flag
- changes having gotten lost altogether (deleted/corrupt replay log (.dat 
file) for example)

Manual recovery would involve either triggering another change on that item or 
forcefully resetting the dirty flag. Automatic recovery would be preferably of 
course, but once you have a real conflict that's tricky. For LLCONFLICTS we 
have the infamous conflict resolution dialog.

I hope this helps a bit.

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/20120719/f8a19e7a/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/


More information about the kde-pim mailing list