https://bugs.kde.org/show_bug.cgi?id=436550
--- Comment #3 from David C. Bryant <davidbry...@gvtc.com> --- I guess I have a work around. I copied all the contents of ./local/share/local-mail/inbox to a new location. Then I closed KMail, stopped Akonadi, and deleted all the messages in ./local/share/local-mail/inbox. When I restarted KMail and ran "akonadictl fsck" I saw that 236 "dirty" items had been eliminated. Here is some terminal output. david@localhost ~ $ akonadictl stop david@localhost ~ $ akonadictl fsck 2>&1|grep ^Found Found 13 external files. Found 13 external parts. Found no unreferenced external files. Found 0 parts to be moved to external files Found 0 parts to be moved to database Found 5 collections without RID. Found 0 items without RID. Found 2765 dirty items. Notice the last line ... that used to say 3,001. 3,001 - 2,765 = 236. So there were 236 "dirty" items in my inbox folder. I killed KMail again, then stopped akonadi and copied the messages from the backup copy back where they had come from. I then restarted KMail, and all the inbox messages re-appeared. And when I reran akonadictl fsck, things were stil (partially) copacetic: david@localhost ~ $ akonadictl fsck 2>&1|grep ^Found Found 398 external files. Found 398 external parts. Found no unreferenced external files. Found 0 parts to be moved to external files Found 0 parts to be moved to database Found 5 collections without RID. Found 0 items without RID. Found 2765 dirty items. So I guess I can cure my KMail error messages by repeating this procedure for all the destinations in my folder tree. But I'd like to understand what created the "dirty" items in the first place. And it would also be nice to have a less labor-intensive method to correct this problem if and when it does arise. (I'm not real hot with "C++". But I used to write database driver software in assembly language on IBM mainframes. It's pretty clear to me that a bunch of the pointers in Akonadi's relational database were corrupted somehow, leading to a lot of "dirty" items. When I removed all the data from one -- well, actually, two -- folders, a whole slew of pointers were cleared from the relational database. Then, when I put the data back and restarted Akonadi, the previously corrupted pointers were rebuilt correctly. So now a bunch of "dirty" items are gone. If some clever C++ programmer could figure out how to make Akonadi reconstruct all its relational database pointers without actually moving a lot of data around, he could at least construct a recovery tool that would probably be useful. Reading a bunch of forum posts, it's obvious a lot of people are unhappy with Akonadi.) -- You are receiving this mail because: You are the assignee for the bug.
