This is a KDE bug and not really appropriate for this tracker.

This is a KDE bug and not really appropriate for this tracker.

Also noticed this and created an upstream report as well: https://bugs.kde.org/show_bug.cgi?id=485308

Thanks. I wonder if we should inform distros about this?

Fixed in 24.02.2

We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190

This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198

Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.

To reproduce:

• Send a mail to yourself
• add an attachment
• select encrypt

I can test this. For Ebo I want to try using the flatpack so that she can benefit from Dans work on debian stable, too.

I encouraged Eva to create this ticket. While the specific case described here might be fixed in current master, the attachment handling still has issues.

With KMail 5.23.1 the attachment icon is shown as icon. It's also show in the header (I don't see a way to disable this).

This has most likely been fixed already with https://invent.kde.org/pim/messagelib/-/commit/70f39256784280d2034aa7bf1c4765f606c22d56. Please retest with KMail 5.23.1 or later.

In T6891#180473, @aheinecke wrote:

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

In T6891#180474, @ikloecker wrote:

I'm also wondering why syncing a handful of new messages takes so long. Or, actually, why syncing takes so long even if nothing at all changed on the server (the new messages were already shown by KMail). Maybe it's just the bad IMAP implementation of Exchange. Or maybe Akonadi has marked the folder as bad, so that it always syncs the entire folder.

My hypothesis about what happens:

• I enter a folder with some new messages. KMail starts a sync.
• I read some of the new messages. They are marked as read in KMail and (hypothesis) Akonadi records the status changes for later because a sync is running.
• The sync finishes. KMail shows the new messages again as unread which (hypothesis) is what the sync reports.
• In the background Akonadi syncs the deferred status changes to the server. (hypothesis)

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

Both the company and me are running debian dovecot.

It seems I'm using Exchange (account at my old university and o2mail.de).

Could you share what IMAP server software do you run personally and in the office (probably Dovecot or Cyrus IMAP?).

Your comment on speed might also be why I do not see this issue. Nearly all of my mails and all my large folders go through my private mail server that stands at a dedicated hoster. While our company mail server is located in the office and only reachable through the office internet connection with VPN afaik. I had a tool / command to deliberately slow down connections on some port maybe you can use something like that? I don't think that we can give you access to the company mail server / VPN since you are not a regular employee.

But I guess syncing a second client should do the trick to get the server state. At least ebo has afaik both claws and kmail configured with the same server.

No, our webinterface is telnet :)

Is there also a web interface for the @gnupg.com mail server? It would be useful to be able to check what's the read/unread status on the server.

I saw this recently on a imap subfolder with between 4- and 5000 mails. I have marked a few hundred new ones as read in one go. The folder does not even have mail threads in it and I've never used that function anyway.
This was on my work account @gnupg.com (the only account where I use KMail). Should we ask Werner for details of the server?

I'm seeing this on an inbox with about 4,000 messages. It may depend on the server (speed) because I'm not seeing this on larger folders on another server. But it does happen for more than one server. I'm not using "Ignore thread". Just the plain old mailing-list style message list. I'll keep an eye on when it happens for which folders.

Also, are you using the "Ignore thread" function?

Can you be more specific how much is "many messages"? Is it tens, hundreds, thousands, tens of thousands? :)

It is okay for you to start with option so "akonadictl --migrate" but I would suggest deleting the old DB only as an option. Especially if error handling is not 100% perfect there should be also an easy way to restore your old config.

Requests to be able to migrate to SQLite without losing data/configuration has been requested multiple times since we blogged about the improvements in SQLite support.

Since 23.08.2 the crash is gone again as expected. Thanks. Btw. do you know which was the first version that had this crash? I am a bit worried that our fellow debian stable users in the office might be affected with the next debian upgrade. Since we use signed / encrypted mails a lot. :)