If a message is moved from one imap folder to another by dragging it to a new folder, it disappears in the old folder - which is correct. If I navigate to that new folder, the message appears correctly in that folder. But if I navigate back to the old folder, the message appears again but it is greyed out now. So the message finally appears twice: Once in the new folder and once in the old folder (but greyed). I am not able to open/move/... the greyed message in the old folder. It just stays there. Even if I refresh the folder or close and open kmail again. If I open the imap account in another mail client like thunderbird, it seems like it "cleans up" the greyed message because then it also disappears in kmail. I have never had any problems with that imap account in any other email client. Reproducible: Always Steps to Reproduce: 1. Drag message from one folder to another folder 2. Select "Move" in the appearing menu 3. Navigate to the destination folder 4. Navigate back to the source folder Actual Results: The moved message appears greyed and cannot be opened, moved or deleted anymore. Expected Results: The moved message does not appear in the source folder.
Additional information: imap server is dovecot 1.2.15 running on debian 6.0 squeeze. The connection is TLS secured.
Quite the same problem here: message are copied instead of moved. IMAP server is courier 4.4.0, runninig on a debian 5.0.9. Icedove works fine, so server is OK. Following a wire sniff when moving messages with both Icedove and Kmail: ################################################################ ######################## ICEDOVE ############################### ################################################################ >>> 20 uid copy 4301 \"INBOX.SVN.folder\"\x0d\x0a <<< 20 OK [COPYUID 1351590453 4301 201] COPY completed.\x0d\x0a >>> 21 uid store 4301 +FLAGS (\\Deleted \\Seen)\x0d\x0a <<< * 1109 FETCH (UID 4301 FLAGS (\\Seen \\Deleted))\x0d\x0a <<< 21 OK STORE completed.\x0d\x0a >>> 22 noop\x0d\x0a <<< 22 OK NOOP completed\x0d\x0a >>> 23 getquotaroot \"INBOX\"\x0d\x0a <<< * QUOTAROOT \"INBOX\" \"ROOT\"\x0d\x0a <<< * QUOTA \"ROOT\" (STORAGE 220602 500000)\x0d\x0a <<< 23 OK GETQUOTAROOT Ok.\x0d\x0a >>> 24 UID fetch 4304:* (FLAGS)\x0d\x0a <<< 24 OK FETCH completed.\x0d\x0a >>> 25 IDLE\x0d\x0a <<< + entering idle mode\x0d\x0a ################################################################ ########################## KMAIL ############################### ################################################################ >>> A004670 UID COPY 4304 \"INBOX/SVN/folder\"\x0d\x0a <<< A004670 NO Error in IMAP command received by server.\x0d\x0a >>> A004671 UID FETCH 4303 (BODY.PEEK[] UID)\x0d\x0a <<< * 1111 FETCH (BODY[] {2478}\x0d\x0a
Count me in this bug too :( Moving a message makes it disappear from the source directory and appear in the destination directory. But then when I come back in the source directory, the emails are still there (not greyed out though). I had a thunderbird accessing the same server simultaneously, and from what I see, mails are copied, not moved. I'll try to see what is going on from dovecot's point of view (2.0 here) on monday. Kde 4.11.2-1 on archlinux here.
I may have found something: I only have the problem when moving several mails at once. It doesn't seem to occur when I do them one by one.
Hi, i have the same bug kdepim-kmail 4.14.1-1 on manjaro linux server imap is dovecot on debian there is two more clients (k9mail) on phone and tablet did you find a solution here ?
if i restart kmail, these greyed messages disappears ...
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.