Cleaning up "dirty" items reported by akonadictl fsck

[David Bryant]

I'm currently working on Chapter 7 ("Troubleshooting") of the KMail 
documentation. It's almost done, except for some advice on dealing with 
"dirty" items in the akonadi/mysql database files.

This problem is documented as a bug: https://bugs.kde.org/show_bug.cgi?
id=436550 I have a workaround, but it's quite laborious.

The problem is present if and when one obtains terminal output like this.

~ $ akonadictl fsck 2>&1 | grep ^Found
Found 5 external files.
Found 5 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 6 collections without RID.
Found 3 items without RID.
Found 3001 dirty items.
~ $

>From time to time akonadictl reports 1 dirty item, which KMail/akonadi is 
apparently  able to patch up somehow.  But when I (some way or another) got 
bitten by ~3,000 dirty items last April, KMail became practically unuseable 
(lots of messages could not be accessed, although they were displayed in the 
Message List).

Anyway, I'm hoping some clever programmer out there can think of an easier way 
to fix this problem (when it occurs) than the method I devised. I backed up all 
my email messages, deleted everything from the ~/.local/share/local-mail/ 
directory, then started KMail. Akonadi erased all its DB files when it synced 
with an empty tree. That eliminated the "dirty" items. Then I closed KMail & 
akonadi and restored the backup copy of all my messages. When I restarted 
KMail, akonadi rebuilt the mysql DB files cleanly. But I lost some auxiliary 
information (special folder properties, for instance), and some of my mail 
filter rules had to be reconstructed. So it was a lot of work. Is there a 
simpler way to fix the "dirty" items when they arrive en masse?

Thanks. Any and all suggestions are welcome.
-- 
David Bryant
Canyon Lake, Texas
https://davidcbryant.net