GNOME Bugzilla – Bug 330838
new/removed IMAP folders recognized late
Last modified: 2013-09-10 13:57:41 UTC
Evolution will not recognize new IMAP folders the first time, but the second time only. Steps to reproduce: * Create a new mail folder on the IMAP server, but do not use Evolution to do this. Easy for me, cause my IMAP server is configured to use mbox format. So a 'touch' does this step for me. * Restart Evo. Note, that the just created new IMAP folder is *not* visible in the UI. * Restart Evo a second time. This time you finally do get the new mail folder. A guess: Evolution instantly displays the mail hierarchy as it was the last time. This is good for a fast startup. While checking for new mail in all folders, Evo realizes there is a new mail folder. However, it fails to update the mail folder tree and actually display this new folder. After a second start, Evo again instantly displays all folders it knew about before. And this time, the new folder actually is visible. Account configured to check all folder for new mail, and to check periodically. Evolution 2.4.2.1, IMAP server is Dovecot. Reproducible: always
*** Bug 332108 has been marked as a duplicate of this bug. ***
Thanks for merging my bug with this bug with this one. I can confirm and reproduce this bug.
Confirming as per comment 2. Thanks, Robert. Robert, so starting Evo for the second time actually updates the tree for you, too? (This wasn't mentioned in your bug, so I'll just want to verify this indeed is a duplicate and the same behavior and workaround.)
Just verified this with Evo 2.5.91 as well. Additional information: * The same behavior can be observed when *removing* a mail folder (not using Evo). I suspect the very same reason as mentioned in comment 0. Adjusting the Summary to reflect this.
Hi Karsten, In reply to your question: We have multiple folder issues (we use courrier-imap). Creating a folder in web client and starting and restarting evo makes the folder show up. This is this bug #330838. This bug is clear and reproducable. Today in some cases we also observe: Create new folder on web client, start evo, folder won't show up, restart evo, folder wont show up, toggle "Show only subscribed folders" to "True", folder will show up, even though this folder was never subscribed to. This is my original bug, so we might reactivate bug #332108, but now this does not always happen, which is hard for debugging, this might even be solved if this bug is solved. An upgrade problem: Old folders, which long before the evo update to 2.4.2.1 were already deleted, suddenly reappear cant be accessed and are hard to delete (this is hard to reproduce because users after some frustrating moments somehow get rid of them). Folder name bug: Create a folder wiht "&" e.g. "this & that" on web client, evolution makes of this name "this &- that", and the folder can't be accessed. Renaming the folder in evolution back to "this & that" solves the issue (this might be made into a separate bug report, please advice). We have had multiple folder issues in 2.4.2.1, we never had this before (and we have been using evo for a long time now). I put all these problems here, because they might be related. We are even holding back our next upgrade for this reason. gr. Robert
Due to the great number of production issues in evolution2.4.1 (debian) we now installed 2.5.92. We can still reproduce this bug (the need to start, close and restart) for folders to be shown. A lot of other issues however appear to be gone in this version (like displaying long deleted folders, and the "&" problem seems to be solved. We now regard 2.4.1 as an unstable version and will focus on 2.5.xx
Please note that 2.5.x actually is the current development branch (read: unstable) and 2.6.x will be the next stable branch. Evolution 2.6.0 will be release on March 13.
also see bug 333867
*** Bug 333867 has been marked as a duplicate of this bug. ***
Since this bug causes a lot of confusion and can be observed in quite some differnt environments, I am bumping the Priority. It is a really bad thing and poor behavior, that Evo trusts his cached data entirely and doesn't react to changes on the server. Accessing Mail from different machines exactly is the reason for IMAP in the first place. This one needs to be fixed ASAP.
I aggree, we have had even users wanting to and moving away from evolution. I had to do a lot of convincing :) I am glad this bug is now upfront.
I just tested again and the problem still exists. A deleted folder on the imap is displayed even after stopping and starting evolution multiple times. The biggest issue for the enduser is not having control. Is it an idea to add a refesh menu item when you do a right click on the mail folder? - though I dont know how difficult this is to achive. our current version is: 2.6.1
I can confirm that this bug still exists with 2.12.0.
*** Bug 327329 has been marked as a duplicate of this bug. ***
*** Bug 462943 has been marked as a duplicate of this bug. ***
Still exists with 2.12.2.
Created attachment 113536 [details] [review] proposed eds patch for evolution-data-server; hmm... event here, event there...
Looks fine, push to trunk.
Committed to trunk. Committed revision 9067.