Version: Git (master) (using Devel) OS: Linux When moving (yes, moving) emails from one folder to another, KMail & Akonadi send IMAP UID COPY commands to the server. However, the mail folder listing in KMail shows all emails as done moving. There's no indication in the UI anywhere that the copy is still going. The effects of this are: 1) no idea when it's safe to shut down or suspend the computer 2) some actions that require interaction with the IMAP agent are not responsive, such as checking a folder properties Reproducible: Always Steps to Reproduce: 1) select some emails in a folder 2) move them to another folder in the same IMAP server (I used the 'm' keyboard shortcut) Actual Results: Emails shown moved immediately, no other UI shows that the IMAP agent is still working Expected Results: Emails should be moved gradually on the UI as they are moved on the server. At the very least, the IMAP agent should show that it's busy somehow. KMail shows absolutely no progress bar for this, and Akonadi Console shows "Connection established" (instead of "Ready") OS: Linux (x86_64) release 3.1.6-1.fc16.x86_64 Compiler: gcc
Created attachment 67300 [details] Screenshot showing the "state" At least in this particular case now it's showing something. It says it's "Ready" but it isn't, as no action seems to have an effect (they are actually queued and will happen later). It says 100%, but it's not done.
Created attachment 67302 [details] Another screenshot, showing similar but not same problem This is another screenshot of an IMAP agent in a "stuck" state. It reads "Connection established". There is absolutely no clue what it's doing and when it's going to be ready. Unless I use Akonadi Console or the this settings dialog, there's also no UI indication that the agent is busy with something. Meanwhile, any actions with the folders and messages in this IMAP account will simply stall. At least for viewing emails it shows "Receiving folder contents". For anything else, there's no UI feedback about anything happening. Note: this one, in particular, was not doing email copies.
More information on the move job that resulted in attachment 67300 [details]: On Akonadi and KMail, the emails were moved immediately from one folder to the other. The IMAP agent did something. There was a lot of (encrypted, sorry) traffic going on for a while (with no indication of when it would finish). That traffic has ended. The UI has not changed from the screenshot. The IMAP agent is *still* stuck. It will not synchronise email, it will not display folder properties. Worse: the emails in the server *WERE* *NOT* moved. They are still in the original folder and the destination folder shows no trace of them.
Akonadi Console's Browser shows the items in the destination folder, not the original one. However, in the "Remote id" column, it shows numbers that clearly belong to the original folder, not the new one. That tells me something went VERY wrong with the copy. It didn't copy.
Telling the agent to restart produced no result: the agent would not restart. It would not receive any commands. After I killed it, akonadiserver respawned it. It reconnected to the server and proceeded to *DELETE* all the emails in the origin folder (mark them with flag \Deleted). I will report another bug for this data loss.
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.