Version: 2.1.0 (using KDE 4.6.4) OS: Linux If I am looking at a new message coming in the message is marked as read immediately as one would expect. Then after a new mail check sometimes the message is marked new again. Usually I am still on the message in the list. It appears it might be related to reading it before the mail check is completed for that account. Reproducible: Sometimes Steps to Reproduce: have a new message come in read it and stay on that message and do a new mail check. Actual Results: Message which was marked as read gets set to unread. Expected Results: message remains as read. OS: Linux (x86_64) release 2.6.38-8-generic Compiler: cc
Bug 277675 and bug 278737 sound similar.
Perhaps, I was able to work around the problem by removing all the akonadi database and starting over again. It seems to be related to the conversion process. I have since abandoned that on all my other boxes and haven't seen the problem since. I still think there is a bug that needs to be fixed, but it is not bothering me any more.
I'm using kmail 4.7.4 and have the same problem. In the configuration dialog I've set "Mark selected messages as read after 0 sec". I read the mails not with double clicking it, but in the "preview frame". I'm not sure, but it seems that issue will not appear if the mail is opened into a new window.
I have the same problem with 4.8.0. I have 2 IMAP accounts (one of them GMail) and it happens every time on both accounts and on all folders.
Danny, what type of account did you have the problem with?
As in bug 278737 I was suggested to create a new bug report for IMAP accounts and I can't understand whether this bug report is for IMAP accounts or not, I created a new (similar) bug report for IMAP accounts: 294074.
This was definitely for IMAP accounts. I didn't know people still used POP ;).
Further information re this bug: it appears that the "read" status is not being pushed back to the IMAP server correctly. Running KMail2 with a dovecot IMAP server running on another box, using Maildir mail storage which made it easy to spot the problem. With dovecot, when the mail is marked as "read" the filename is suffixed with an "S". Mails marked for deletion are marked with a "T". The flags are cumulative i.e. a read mail marked for deletion will have "ST". I connected via an ssh console session to the mailserver and went to Maildir/.<Mailbox>/cur an did "ls -l". Here is the directory contents: -rw------- 1 bakerr bakerr 5013 Feb 6 18:09 1360136366.10220_3.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 6797 Feb 6 19:30 1360141187.10935_2.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 5134 Feb 6 19:35 1360141553.10983_0.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 5497 Feb 6 20:20 1360144218.11362_1.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 7073 Feb 7 02:14 1360165472.14541_2.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 7654 Feb 7 02:19 1360165775.14586_1.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 5844 Feb 7 02:20 1360165775.14590_3.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 9800 Feb 7 02:50 1360167604.14959_2.mailpi.vk5ztv.ampr.org:2, Now, I read all the mails and again do ls -l: -rw------- 1 bakerr bakerr 5013 Feb 6 18:09 1360136366.10220_3.mailpi.vk5ztv.ampr.org:2,S -rw------- 1 bakerr bakerr 6797 Feb 6 19:30 1360141187.10935_2.mailpi.vk5ztv.ampr.org:2,S -rw------- 1 bakerr bakerr 5134 Feb 6 19:35 1360141553.10983_0.mailpi.vk5ztv.ampr.org:2,S -rw------- 1 bakerr bakerr 5497 Feb 6 20:20 1360144218.11362_1.mailpi.vk5ztv.ampr.org:2,S -rw------- 1 bakerr bakerr 7073 Feb 7 02:14 1360165472.14541_2.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 7654 Feb 7 02:19 1360165775.14586_1.mailpi.vk5ztv.ampr.org:2,S -rw------- 1 bakerr bakerr 5844 Feb 7 02:20 1360165775.14590_3.mailpi.vk5ztv.ampr.org:2, -rw------- 1 bakerr bakerr 9800 Feb 7 02:50 1360167604.14959_2.mailpi.vk5ztv.ampr.org:2, At this stage ALL the mails are marked as "read" in KMail2, but not all the mails have "read" status flags on the mailserver. The next time KMail2 syncs with the IMAP server, those mails go back to unread status in KMail2. If I issue a "Mark all mails as Read", all mails are marked as unread but the status are NOT updated on the dovecot mail server until the next scheduled mail check. I have seen the same thing happen with IMAP on gmail (I don't know what they run in the back end). "Read" status updates should either be pushed back to the mailserver as soon as they are changed in KMail2, or remembered locally and changed correctly on the mailserver at each scheduled mail check. There should also be a means of verifying that the change of status has been accepted and actioned by the mailserver and an error message should be displayed after a reasonable number of retries if the operation fails.
Further to that, the number of messages that do not get their status updated correctly on the mailserver when marked locally as "read" (by reading them in the preview pane) varies from a few (2 or 3) to all messages in the mailbox (esp. if is >20-30 messages). It does not seem to be consistent or necessarily predictable (yet).
Try to enable IMAP logging and see if there is any error. See http://techbase.kde.org/Projects/PIM/Akonadi/Debug_IMAP
After watching the log file for quite some time (using tail -f) for the relevant akonadi process, the IMAP STORE command (with \SEEN flag) is not being sent to the server the first time a mail is fetched. It is only sent on the second fetch. When sent, the STORE command is being actioned and the response "OK Store completed" is returned. No errors from the server that I can see. An example transaction: C: A000548 UID FETCH 25270 (BODY.PEEK[] UID) S: * 65 FETCH ( UID 25270 BODY[] Return-Path: <opensuse+bounces-143179-rodney.baker=iinet.net.au@opensuse.org> [...message body removed...] S: A000548 OK Fetch completed. The next time the folder is refreshed, note the lack of SEEN flag on UID 25270: S: * 64 FETCH ( FLAGS () UID 25269 ) S: * 65 FETCH ( FLAGS () UID 25270 ) S: * 66 FETCH ( FLAGS () UID 25271 ) S: * 67 FETCH ( FLAGS () UID 25272 ) S: * 68 FETCH ( FLAGS (\Seen) UID 25273 ) S: * 69 FETCH ( FLAGS () UID 25274 ) S: * 70 FETCH ( FLAGS () UID 25275 ) The next time the message is selected (after another folder refresh): S: * 63 FETCH ( FLAGS (\Seen) UID 25268 ) S: * 64 FETCH ( FLAGS () UID 25269 ) S: * 65 FETCH ( FLAGS () UID 25270 ) S: * 66 FETCH ( FLAGS () UID 25271 ) S: * 67 FETCH ( FLAGS (\Seen) UID 25272 ) S: * 68 FETCH ( FLAGS (\Seen) UID 25273 ) S: * 69 FETCH ( FLAGS () UID 25274 ) S: * 70 FETCH ( FLAGS () UID 25275 ) S: A000565 OK Fetch completed. C: A000566 UID STORE 25270 FLAGS (\Seen) S: * 65 FETCH ( UID 25270 FLAGS (\Seen) ) S: A000566 OK Store completed. This pattern is consistently repeatable. I have the full log as a tgz archive - I'm happy to email it to someone but I'd rather not attach it here. Rodney.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.