I’ve been a very happy Kmail user for a long time but have recently struck a number of problems, and I’d like to know if anyone else can confirm anything similar or related.
(1) I have my folders organised “Manually, by Drag And Drop” (by right-clicking on the “Name” bar at the top). But some top-level folders randomly seem to go to the bottom of the list, “wastebin” and “Archive” for example, and they’re restored to the correct manually set position immediately when clicked.
(2) Folder message-lists (except one) are sorted “Least Recent on Top” and focus goes to the message last read. But occasionally focus stubbornly stays on the message at the top, apparently because the message there has no “Date” shown in the message-list, even though it has a delivery-date header and it’s not the one last-read. It’s as though the message index just loses that field. Clicking on the folder, going to Folder Properties > Maintenance tab > Reindex current Collection" doesn’t fix the problem.
(3) Moving messages between folders sometimes results in duplicate messages, as though messages are copied rather than moved, and a new-message notification comes up. Deleting the unwanted copy eventually works but sometimes it reappears for a while, perhaps until the indexer catches up.
These problems sound to me as though message indexing and its interface to the GUI needs attention.
I have another problem with filters, but it might be better described in a separate email. One of the nice things about Kmail is its extensive filtering options.
akonadictl generated an enormous amount of output so quickly that I wasn’t able to check whether any problems were detected / fixed. I then redirected syserr & sysout to a logfile and ran it again. The logfile reported “17,337 items without RID” and that is solid, but apparently only one error:
david@anon:~/Desktop> akonadictl restart
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
david@anon:~/Desktop> Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: “Cannot connect to agent instance with identifier ‘akonadi_maildir_resource_0’, error message: ‘’”
org.kde.pim.akonadiserver: “Cannot connect to agent instance with identifier ‘akonadi_maildir_resource_0’, error message: ‘’”
Does anyone know what a RID is?
I apologise for raising item (2) in my original post, which is fixed. The original message was an automatically-generated receipt sent without a timestamp, and it seems Kmail displays that rather than the timestamp in the “delivery-date” header. Also, the relevant configuration parameter when entering a folder was NOT “jump to last selected message”. Why this suddenly became a problem is a mystery, but life is short.
However item (1) is still a problem. I’ll have to see whether (3) persists, but it seems likely to be a timing issue.
RID seems to stand for “Remote Identifier,”[1] which is a pointer or link to the remote file or folder associated with the item at issue.
With respect to (3), I’ve noticed that, moving mail to another folder tends to place the “moved” mail to the “new” directory of the target folder – even though the moved mail is flagged as being “read”. « I’ve raised a KDE Plasma 5 KMail Bug Report on this theme some time ago but, no progress yet … »
The only viable solution I’ve found to date, is to select the “newly moved” mail items and then <Ctrl-U> and <Ctrl-R> to move the “moved mail” to the folder’s ‘cur’ directory …
BTW, in KMail’s “Folder” menu drop-down, there’s a “Remove double e-Mail” action …
[HR][/HR]As an aside, one of the slightly annoying things about KDE Plasma 5 and Akonadi is that, empty “cur”, “new” and “tmp” directories occasionally get created in the ‘~/.local/share/’ directory tree, with undefined consequences. The following bash script will find these empty directories which can then be removed as needs be:
#!/bin/bash
#
# Search for empty 'cur/', 'new/' and 'tmp/' directories in ~/.local/share/.
#
for j in cur new tmp ; do
for i in cur new tmp ; do
find ~/.local/share/ -type d -path '*'$i/$j -print
done
done
#
Your reply mentioned many familiar issues. While this is not the place to debate architecture, the KDE Forums thread quoted above demonstrates the astonishing complexity of the complete Kmail / PIM package and I wonder how many installations use the full suite of PIM functions. Being based on MySQL would at least make it scalable.
It seems the 17,337 items without a RID may be MySQL database entries created when importing mail from another system, either as an MBOX file or a Kmail archive. I suppose they’re not doing any harm but they wouldn’t help performance either, and I might try deleting them (after first doing a full PIM backup).
I just delete redundant copies until Kmail sorts itself out, which is annoying, and it’s interesting to know the reason.
I’ve noticed that too, but they’re created in the ~/.local/share/local-mail/ directory.
The “no RID” items should be moved to ~/.local/share/akonadi/file_lost+found. However, a while ago I ran into that folder not existing. I recreated it, ran the fsck command again, and they were moved there. Emptying the folder made the RID messages disappear, and returned performance back to normal.
Like Don says, these are messages of which the remote ID no longer exists. Do not ask me for the technical details, I just noticed.
Deleting Items that have no RID by GUI is convoluted. Nevertheless, the first part is to locate what folder/collection the item at issue is in:
In Akonadi Console
Click “DB Browser” tab
In the drop-down option list, select “pimitemtable” and click “Refresh.”
Sort the resulting table by “remoteid,” by clicking on the “remoteid” table header. This should list all items with a blank “remote id” first.
You should now be able to look at the corresponding “collectionid” column to identify the collections/folders where these items with no RIDs live.
The second step will be to select the pertinent collection from the “Browser” tab of Akonadi Console, find the id, right click on it, and delete it.
Note: (See Update below
) If you know of some way to access the the akonadi mysql db directly using the mysql client, you should be able to delete all the problematic items by running something like:> Select all; delete from pimitemtable where remoteid=“”;
‘akonadiconsole’ reveals interesting insights into Kmail. It seems most of the items with no RID were created at the same time, on 15th January 2018. The best way of removing them may be by directly accessing the database, as suggested in the extract above.
That folder had a 1.8 Mbyte file in it, but deleting the file and re-running ‘fsck’ didn’t seem to remove the no-RID items. Thanks for the suggestion anyway…
The “no RID” files located in this directory are in fact “normal” e-Mail files which can be opened by the KMail2 viewer but, cannot be imported by direct means back into a KMail folder.
The solution I use is, to save those ‘lost+found’ “no RID” e-Mail files via the KMail2 viewer to a temporary user directory, and then to import the saved .mbox files into a KMail folder.