kmail sigh

[Sandro Knauß]

Hey,

> I quite appreciate the need for a "reproducer" this a common thing that
> developers ask for and is a reasonable request.
> The trouble with this is that it does not address the real world. To create
> a sane reproducer for this bug is not so easy as it sounds as it is
> possible that the issues occur because of the large volume of mail/headers
> that are being processed. Creating a small scale installation may not
> create the same conditions thus to be representative I need to work with
> the data and mail accounts that I have since this is the real world
> situation. There is already growing evidence that some of the issues are
> load dependent as postgresql seems to perform better than the mysql
> variants.

well the issue is not so common, that the devs can't reproduce them easily. I 
use kdepim a daily - it is my only email reader for many years now. I also 
have tons of mails and use mysql without any longer waiting periods. So for 
many people kdepim works quite well, that's why we need to address the 
surroundings, when this is the case.

> I believe I have provided enough information for you to pinpoint the area of
> code where the failure of fsck is taking place. It is quite evident from my
> report that the part of the code that selects the duplicate to delete from
> the database is flawed in that it is deleting a mail with no body content.
> The fact that there is a mail with no body content in the first place is a
> different bug.  If it is possible to simply fix the fsck bug this would
> give users who have these issues a way forward which at the moment they do
> not have.

As often told on this list - the POP3 setup is currently missing active 
developers with such an setup and the issues there are not in the focus. 
Anyone is welcome helping us to fix the specific issues with this setup. We 
are currently looking at the database itself, what can improved there and 
there is already a list what needs to be done to gain better support.

> As a possible alternative if you as someone who knows the code intimately
> could point me to the code that performs this function I will attempt to try
> and debug it myself. I am familiar with SQL and database structures though
> I am not a C or C++ coder but can understand enough to probably spot what
> is going wrong.

well we don't execute directly SQL, this is done via a ORM, so i think you'll 
have to start looking into the C++ code (akonadi repository):
src/server/storagejanitor.cpp
this function:
void StorageJanitor::check() // implementation of `akonadictl fsck`
than search for the subfunctions...

hopefully this gives you the entrypoint to fix this issue.

> I will file an initial bug with any detailed information I can get from my
> current installation so at least the issue is flagged.

hefee