[Akonadi] [Bug 436550] Sporadic error when moving messages to trash.

[David C. Bryant]

https://bugs.kde.org/show_bug.cgi?id=436550

--- Comment #3 from David C. Bryant <davidbryant at 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 at localhost ~ $ akonadictl stop
david at 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 at 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.