kde-pim Digest, Vol 240, Issue 2

Tue Feb 7 16:52:50 GMT 2023

On Tuesday, February 7, 2023 6:00:04 AM CST kde-pim-request at kde.org wrote:
> I'm using this with a gmx account. I would assume this server is maintained.
> I know nothing about UIDLs. Those duplicated emails cannot be displayed
> (i.e. when clicking on them nothing happens), they always stay  "unread"
> and I cannot delete them.
> 

I am aware of this problem, and I have a work-around. I added it to the KMail 
documentation in Section 7, KMail Troubleshooting.

> Is there something I can do to help ?

Yes. Assuming that you are using mysql (aka mariadb) as your database engine, you can 
use the mysql program to remove the superfluous database rows. An analogous 
procedure should work with sqlite, if you're using that instead..

First, open a terminal window and  find out how many records are lacking RID (remoteid) 
data:
~ $ 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* 17 items without RID. 
*Found* 0 dirty items.

Next, say this:
~ $ ps ux | grep mysql

My system produces the following response:
david    16528  0.4  1.1 3412864 180584 ?      Sl   08:39   0:07 /usr/sbin/*mysql*d --defaults-
file=/home/david/.local/share/ak
onadi/*mysql*.conf --datadir=/home/david/.local/share/akonadi/db_data/ --socket=/run/
user/1000/akonadi/*mysql*.socket --pid-file=
/run/user/1000/akonadi/*mysql*.pid 
david    17666  0.0  0.0   6692  2136 pts/2    S+   09:04   0:00 grep --colour=auto *mysql*

Use the "--socket=" data to invoke the mysql utility program. It will probably come out 
almost the same on your system ... the big variable is the userid, which is usually 1000 (on 
a system with just one user, and root).

~ $ mysql --socket=/run/user/1000/akonadi/mysql.socket

This will start an interactive conversation with the database server.

*~ $* mysql --socket=/run/user/1000/akonadi/mysql.socket 
Welcome to the MariaDB monitor.  Commands end with ; or \g. 
Your MariaDB connection id is 57 
Server version: 10.6.11-MariaDB Source distribution 

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 

MariaDB [(none)]> 

You will have to enter three mysql commands (shown below in bold-faced type):

MariaDB [(none)]> *use akonadi;*
Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 

Database changed 
MariaDB [akonadi]> *delete from pimitemtable where remoteid is NULL; *
Query OK, 17 rows affected (0.005 sec) 

MariaDB [akonadi]> *\q*
Bye
~#

You're now back at the BASH prompt. Verify that the cleanup succeeded:
*~ $* 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* 0 items without RID. 
*Found* 0 dirty items.

I should add a few cautions. First, if you have created more than one address book you 
probably ought to back your address book data up to an external file. Address books in 
Vcard format are stored directly in the akonadi database, and they do not have an 
associated remoteid. So the above *delete *command will remove those address book 
entries -- you'll have to restore the secondary address book from the backup copy. I'm 
pretty sure that the Vcard address books are the only entities that have no associated 
remoteid data. Second, you will have to stop KMail (right-click, then say "quit" if it's 
running in the system tray) and restart it to force reloading of the mysql database files 
beefore the extraneous entries will go away.

Just a word about why this happens. The basic email data are stored in ~.local/share/local-
mail (on most Linux systems). The messages are  stored as separate files, with names like 
1675709976831.R873.localhost:2,S, where the big long number refers to the time the 
message was sent, expressed in milliseconds elapsed since 00:00:00 01/01/1970. There's 
an "akonadi" directory inside ~.local/share -- ~.local/share/akonadi/db_data/akonadi -- that 
contains the mysql database files. These are basically indexes that contain some 
metadata, plus pointers to the actual email files in "local-mail". I don't know exactly why, 
but sometimes, when a message is "filtered" to another folder besides inbox, a job to 
create the database entry is started more than once. Something goes haywire, and you 
end up with two database entries that refer to the same message. But only one of them 
points to the actual email message; the other one contains metadata about the message, 
but lacks the crucial information saying where to find the actual message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20230207/1bf4042f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20230207/1bf4042f/attachment.sig>