Page MenuHome GnuPG

KMail: IMAP flags are sometimes not synced / shown correctly
Open, NormalPublic

Description

While I notice this sometimes with the unread state it usually goes away if I sync again. For me it behaves that If you mark many messages as read in one go that after the sync the mails go back to unread. Then I sync again and the flags are shown correctly. But according to @ebo and @ikloecker for them the Mails stay unread.

Do you two have a good example on how to reproduce this?

Event Timeline

aheinecke triaged this task as Normal priority.Dec 14 2023, 11:48 AM
aheinecke created this task.

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

Is it maybe a specific email server that it happens with?

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

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.

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?

And I don't know if the mails would have reverted to read on their own as I used my shortcut "mark all read" again when I noticed it.

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.

No, our webinterface is telnet :)

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.

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.

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

Connectivity speed is one thing (I can throttle network easily through tc qdisc) , but I think it might have to do with performance of the server itself.

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

Both the company and me are running debian dovecot.

@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?

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)

Hypothesis: At this point, the server has the correct statuses, but KMail shows outdated statuses.

  • On the next sync (e.g. forced with F5), the statuses on the server are loaded and now KMail shows the correct statuses.

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.

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.

Somehow spectacle screencasting does not work too well for me. But you get the idea here. For me syncing the whole folder tree of my 8gb IMAP account takes way less then 10 seconds and for a single folder it is not even noticable.

So a classical case of "your millage may vary"

@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?

Yes, that is basically correct. But due to the problems I have when trying to duplicate this in a publishable way, I can't attach a screencast.

dvratil moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 5 2024, 10:46 AM
dvratil moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Feb 5 2024, 10:25 AM