GNOME Bugzilla – Bug 529199
Evolution cannot fetch summary for large GMail folders via IMAP
Last modified: 2012-06-18 10:44:57 UTC
Please describe the problem: I use IMAP to access my GMail account. Evolution gets disconnected by the server while fetching summary and checking new mail in my [All Mail] folder (the one with all the mail on the gmail account). This folder as around 10000 e-mails. Steps to reproduce: 1. Configure evolution to access a gmail account via imap 2. open a folder with more than 10000 emails (maybe a bit less). Actual results: Fetching summary progresses up to ~30% after which an error occurs: Error while Refreshing folder. Server unexpectedly disconnected: Success Expected results: Fetching the summary should not be interrupted (maybe the server's fault) but any way the first 30% I get seems to be discarded, I have to start downloading the same summaries over and over and it always fails at around 30% Does this happen every time? Yes. Other information: If I create a label containing about 3000 emails, evolution works as expected on the corresponding imap folder. Thunderbird and balsa work fine for the 10000+ email folders. I also tried the "Fastest" option by only selecting basic IMAP headers. It does seem to help a little bit but I actually never reach 40% (and I have filter virtual folders based on mailing lists so I'd like to retrieve all the headers).
I'm having the same problem with Evolution 2.22.1, in gNewSense 2.0. I setup a Gmail Imap account in evolution and when I try to download my emails, it can't sync with the server. This only happens in folders/labels with a lot of emails - i think around 1GB in emails.
Created attachment 110459 [details] I've tried debugging Evolution with the debug symbols package included in gNewSense 2.0, but I had no luck. So, I debuged it with valgrind. This is the result
I was having similar issues using my own libspruce library when connecting to imap.novell.com, so I added some logic to make it flush the summary to disk at periodic intervals (I think after every 1024 message headers fetched). Then, if the connection was dropped, it would simply force a reconnect and then start fetching message summary info starting at the first unfetched message rather than starting all over again at 1. http://sourceforge.krugle.com/kse/codespaces/DFHUr5 take a look at untagged_fetch_all(), specifically line 1000 and 1001 in imap_fetch_all_add(), note that you need to be careful when flushing the summary infos to disk because you MAY get message summary info in ANY ORDER, not necessarily sequentially, so you need to make sure you only flush messages in sequence. e.g. if you have messages 1-99 and 101, you can't flush 101, you can only flush 1-99... you can't flush 101 until you get the complete summary for #100. I may have also ported this logic to camel-imap4, but I don't remember.
I can confirm this happens in 2.22.1 (under Ubuntu Hardy). Fetching summary for the [Gmail]/All Mail folder stalls at around 30%, with results thrown out.
Changing summary to reflect the fact that this is GMail-specific. (I've also several reports of this in Fedoraland, all GMail.)
I can confirm this bug with opensuse as well as newer evolution version 2.22.0. I was able to go past the problem by commenting the lines: // if (type == CAMEL_IMAP_RESPONSE_ERROR) // goto lose; // // /* Free the final tagged response */ // g_free (resp); from function imap_update_summary() of the file camel/providers/imap/camel-imap-folder.c. of course, commenting the g_free causes a memleak, but this is not the point, i'm just testing a concept. with these lines commented out, evolution suceeded in obtaining the entire summary (17139 messages) and proceeded with messages downloading. I don't know what the proper fix really is but the current behaviour seems too strict: everything or nothing. This way it will never work with gmail because they seem to limit the number of download messages/summaries. Jeffrey is right about saving partial result. Currently, in case of error, it will just 'goto lose' therefore freeing everything. Perhaps somebody who knows this code better can suggest a better way of handling errors?
*** Bug 519140 has been marked as a duplicate of this bug. ***
*** Bug 531905 has been marked as a duplicate of this bug. ***
Is it still valid in 2.26.x or later ?
I have a GMail account with similar size and have not seen this problem recently. Can anybody still reproduce this? If so, with which mail account type (IMAP? IMAPx?)
(In reply to comment #10) > I have a GMail account with similar size and have not seen this problem > recently. > > Can anybody still reproduce this? If so, with which mail account type (IMAP? > IMAPx?) Wow. I didn't even remember reporting this bug. I've stopped using evolution around that time so I did not try again. I installed the version of evolution available on ubuntu precise: $ evolution --version evolution 3.2.3 This works like a charm, I could download my "All Mail" gmail folder through imap, with the default settings documented here: http://support.google.com/mail/bin/answer.py?hl=en&answer=78799 Thanks.
It works for me in evolution 2.32.3.
Thanks everybody!