GNOME Bugzilla – Bug 720128
[courier]: Mail folders disappear and filters 'disabled' as a consequence
Last modified: 2014-09-09 15:28:37 UTC
Since updating to Evolution 3.11.2, my evo is 'misbehaving' in a weird way (imapx configured from within EVO, not GOA) - Upon lunch, several folders from my imap account are not visible - As a consequence, evo disables the mail filters for those folders (so it really 'misses' them) Checking folder subscriptions on the server, they are all 'selected' (marked). De-selecting and re-selecting the folder makes it re-appear in the folder list. The filters need to be corrected to apply for mails until next restart of Evo. This is with my own courier-imap server (don't have another plain imap server for testing.. I have another gmail and EWS account, both configured through GOA).
Can you run "CAMEL_DEBUG=imapx:io evolution" and try and to capture the IMAP log up to and including the LIST command output? Also give an example of a folder that's not showing up so I can compare it against the IMAP log.
I created a log file (it's 4.5MB; compressed and attached); Seems surprising that 'some' mail header data is in this log... An observation made in plus: 'waiting' seems also enough to get the folder structure back in place (but the filters remain disabled).
Created attachment 263863 [details] Evo log file
That's strange, it's not issuing a 'LIST "" *' command after connecting. It's just doing it for individual mailboxes, probably as you select them in Evolution. That would explain the initially missing folders. Now the question is 'why'.
(In reply to comment #4) > That's strange, it's not issuing a 'LIST "" *' command after connecting. It's > just doing it for individual mailboxes, probably as you select them in > Evolution. Hmm. I pretty sure I refrained from clicking in the UI... upon start, the folders were 'mostly' there.. shortly after 'mostly' gone (all collapsed) and the starting re-appearing... > That would explain the initially missing folders. Now the question is 'why'. now THAT is a good question; knowing you, the answer is close :)
I tried my own account on your Courier server, and the log shows immediately after obtaining namespace info it lists all available mailboxes Here's the opening sequence in my log: C: A00004 NAMESPACE S: * NAMESPACE (("INBOX." ".")) NIL (("#shared." ".")("shared." ".")) S: A00004 OK NAMESPACE completed. C: A00005 LIST "" "INBOX.*" S: * LIST (\HasNoChildren) "." "INBOX.Subfolder_B" S: * LIST (\HasNoChildren) "." "INBOX.Subfolder_A" S: * LIST (\HasNoChildren) "." "INBOX.Subfolder_C" S: A00005 OK LIST completed ... C: A00007 LIST "" INBOX S: * LIST (\Marked \HasChildren) "." "INBOX" S: A00007 OK LIST completed ... C: A00010 SELECT INBOX ... Whereas your log shows: C: B00006 NAMESPACE S: * NAMESPACE (("INBOX." ".")) NIL (("#shared." ".")("shared." ".")) S: B00006 OK NAMESPACE completed.^M C: B00012 LIST "" INBOX S: * LIST (\Marked \HasChildren) "." "INBOX" S: B00012 OK LIST completed ... C: B00017 SELECT INBOX ... It's missing the LIST "" "INBOX.*" command, which is how the client learns what mailboxes are available on your server. Instead it's learning about mailboxes individually in an ad-hoc fashion, perhaps from your filters asking for them. Can you try some gdb breakpoints for me? I'm working backwards from where the command _should_ be called, to try and figure out where you're veering off. Try setting each of these breakpoints in gdb in the order shown until you hit one of them. Restart Evolution between each try. You should hit them almost immediately, maybe even before the main window shows up. fetch_folder_info_for_namespace_category sync_folders imapx_store_get_folder_info_sync folder_tree_row_expanded
Oh, I forgot to mention: disable all your other IMAP accounts before debugging. Otherwise they'll interfere, and you'll get false positives.
fetch_folder_info_for_namespace_category => did not break sync_folders => Did not break imapx_store_get_folder_info_sync => did not break folder_tree_row_expanded => breaks (I was starting to doubt if i set the breakpoints wrong).
(one observation: the behavior of folder refreshing changes between the option 'show only subscribed folders' being toggle on/off. The log file still did not show A00005 LIST "" "INBOX.*" though
Hmm, the breakpoint results are strange. Can try another breakpoint? camel_store_get_folder_info_sync I think you should hit this one. If you do, can you step through the function and see if it's bailing out before it gets to the class->get_folder_info_sync() call? There's only one exit path before it, but you should be getting an error if it's taken. Here's the code you're stepping over, for reference: https://git.gnome.org/browse/evolution-data-server/tree/camel/camel-store.c?id=EVOLUTION_DATA_SERVER_3_11_2#n2138
Seems to have gone pretty much as expected? (gdb) next 2153 g_return_val_if_fail (CAMEL_IS_STORE (store), NULL); (gdb) 2156 g_return_val_if_fail (class->get_folder_info_sync != NULL, NULL); (gdb) 2158 name = camel_service_get_name (CAMEL_SERVICE (store), TRUE); (gdb) 2159 camel_operation_push_message ( (gdb) 2158 name = camel_service_get_name (CAMEL_SERVICE (store), TRUE); (gdb) 2159 camel_operation_push_message ( (gdb) 2161 g_free (name); (gdb) 2164 if (!store_maybe_connect_sync (store, cancellable, error)) { (gdb) [New Thread 0x7fffd4843700 (LWP 9358)] 2169 info = class->get_folder_info_sync ( (gdb) 2171 if ((flags & CAMEL_STORE_FOLDER_INFO_SUBSCRIBED) == 0) (gdb) 2169 info = class->get_folder_info_sync ( (gdb) 2171 if ((flags & CAMEL_STORE_FOLDER_INFO_SUBSCRIBED) == 0) (gdb) 2172 CAMEL_CHECK_GERROR ( (gdb) 2176 allow_virtual = ((flags & CAMEL_STORE_FOLDER_INFO_NO_VIRTUAL) == 0); (gdb) 2177 start_at_root = (top == NULL || *top == '\0'); (gdb) 2210 } else if (info == NULL && !start_at_root && allow_virtual) { (gdb) 2178 store_has_vtrash = ((store->flags & CAMEL_STORE_VTRASH) != 0); (gdb) 2210 } else if (info == NULL && !start_at_root && allow_virtual) { (gdb) 2268 camel_operation_pop_message (cancellable); (gdb) 2281 return info; (gdb)
A new pristine account does not show this behavior. When changing the receiving options though, I could reproduce the same on a fresh account.
Created attachment 264096 [details] With this set of options, the issue appears...
(In reply to comment #12) > A new pristine account does not show this behavior. > > When changing the receiving options though, I could reproduce the same on a > fresh account. Let me complete this sentence: It requires the following two check boxes to be enabled (together.. one alone does not trigger it) * Check for new messages in all folders * Show only subscribed folders
For my account on your server, I set the options exactly as in comment 13 and restarted Evolution. It issued the LIST "" "INBOX.*" command on startup, so there must be something else to this. I don't remember exactly where we left off on the debugging. If you still have a non-optimized build handy, I'll still like to know which of the breakpoints in comment 6 you're hitting or not hitting.
(In reply to comment #15) > If you still have a non-optimized build handy, I'll still like to know > which of the breakpoints in comment 6 you're hitting or not hitting. Dominique?
:( I am no longer able to reproduce this issue - strange as it sounds. I will just close the bug for now.