kmail sigh

[Colin Close]

Hi Pablo,
I haven't created any bugs because, as you have observed it is notoriously 
difficult to describe. Since there was no response last time I posted this I 
assumed that the problem was already known.
I'm happy to provide some screen shots and the like if that will help make the 
situation clearer.
Put as simply as possible the sequence runs like this.

1: By means of a number of mechanisms, filters having the highest probability, 
a duplicate is introduced into the database but the duplicate is a ghost in 
that it only contains the header of the mail and not the body of the message.
This is directly observable in the akonadi db tables.

2. The user runs akonadi fsck which supposedly deletes the duplicates. During 
this process the original message (i.e. the one that actually has a body) is 
deleted from the database. This leaves the ghost message in the db (i.e. the 
one that has no body).

3. When kmail is started a check is run on the all folders to ensure that all 
messages have been loaded. At this point kmail/akonadi discovers the unindexed 
mail (remember that the "wrong duplicate" has only been deleted from the db by 
"akonadi fsck"  it has not been deleted from the local folders) and so 
recreates the missing mail in the db once again. Hence "akonadi fsck" can 
never remove a duplicate.

4. What makes matters really bad is that even if you try to clean out the 
duplicates by using the utility in the "folders" menu it can never remove them 
because it is only the headers that match not the bodies thus they are both 
seen as unique messages. The utility may not see the ghost duplicate at all 
since it is possible that it only exists in the database but I am not sure 
about this and considered that the inability of "akonadi fsck" to remove the 
correct duplicate was enough to at least allow the cleaning of duplicates to 
be fixed.

I am happy to give more details if required.

Best,
Colin Close 

On Tuesday, 30 January 2018 00:18:49 GMT Pablo Sanchez wrote:
> Hi Colin,
> 
> Thank you for posting this message.  For me, it's a bit difficult to
> follow but there seem to be some gems which may be actionable.
> 
> Are there any bugs created for the observations?
> 
> Thx!
> 
> On Mon, 29 Jan 2018 23:16:16 +0000, Colin Close wrote:
> > [ trimmed ]
> 
> --
> Pablo Sanchez - Blueoak Database Engineering, Inc
> Ph:    819.459.1926        iNum:  883.5100.0990.1054