Bug 290316

Summary:	No visible UI indication of copy jobs running in the background
Product:	[Applications] kmail2	Reporter:	Thiago Macieira <thiago>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal
Priority:	NOR
Version:	Git (master)
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Screenshot showing the "state" Another screenshot, showing similar but not same problem

Description Thiago Macieira 2012-01-01 13:42:32 UTC

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

Comment 1 Thiago Macieira 2012-01-01 14:12:26 UTC

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.

Comment 2 Thiago Macieira 2012-01-01 14:24:47 UTC

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.

Comment 3 Thiago Macieira 2012-01-01 14:41:45 UTC

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.

Comment 4 Thiago Macieira 2012-01-01 14:44:13 UTC

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.

Comment 5 Thiago Macieira 2012-01-01 14:50:05 UTC

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.

Comment 6 Denis Kurz 2016-09-24 18:22:11 UTC

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.

Comment 7 Denis Kurz 2017-01-07 22:41:24 UTC

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.