Re: kde-pim Digest, Vol 240, Issue 2

David Bryant <[email protected]> Tue, 07 Feb 2023 10:52:50 -0600

Newsgroups	gmane.comp.kde.devel.pim
Message-ID	<1961317.AT6SoxRAfo@localhost>

On Tuesday, February 7, 2023 6:00:04 AM CST [email protected] 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.

signature.asc (application/pgp-signature, 488 B)