https://bugs.kde.org/show_bug.cgi?id=362398
--- Comment #5 from Martin Koller <kol...@aon.at> ---
BTW: I once tried to find the root cause of the duplicate emails and came up
with the following:
I'm hunting the "duplicate mail bug" and I think I've found a bug in the
Akonadi Server.
What happens here is the following:
- a resource adds a new mail item (id=3, collection=17)
- Akonadi sends "Item added" to the filter agent
- filter agent sends a "move" command to move item id=3 from collection=17 to
collection=19
- Akonadi sends "item added" to the maildir resource (this is the first "added"
message from the creation, so the
item still has id=3 collection=17)
- I'd say in the Akonadi DB the collectionId of item=3 is now 19 (after the
move)
- Now the maildir resource gets triggered by its internal file watcher and
triggers a sync
- maildir gets called with retrieveItems and lists what it has on disc, which
is the item (id=3) in the collection=17
- Akonadi receives this and inside Merge::parseStream() there the bad thing
happens:
It hits this "if" branch (server/src/handler/merge.cpp Line 301)
// No item with such GID/RID exists, so call AkAppend::insert() and
behave
// like if this was a new item
and INSERTS the item AGAIN into collection=17 with a new id=4
Now I have the same mail item twice in the DB
Since the maildir "itemsRetrieved" answer contains for the first time the RID,
the newly inserted item gets this RID,
and the previously intserted one id=3 does not and is left alone with a NULL
RID
Someone more knowledgeable about the Akonadi internals should have a look,
please.
--
You are receiving this mail because:
You are watching all bug changes.
