GNOME Bugzilla – Bug 514300
IMAP INBOX capitalization error
Last modified: 2008-04-17 21:20:52 UTC
Please describe the problem: Using evolution offline mode does not work with AOL.de. Apparently the reason is that they have an "Inbox" while evolution prefers "INBOX". When starting up offline, "INBOX" is not found in .ev-store-summary (called from camel-store-imap.c:2071) and thus an error message appears "No such folder INBOX". For other imap servers sending "INBOX", this problem does not appear. Submitted as debian bug #463238. Steps to reproduce: 1.a Evolution in online mode 1.b create AOL.de account, setup evolution account 1.c make Inbox available offline 2. Go offline, quit evolution 3. Start evolution again in offline mode Actual results: Error message "No such folder INBOX". Inbox not available in offline mode. Expected results: Inbox available in offline mode. Does this happen every time? Yes. Other information: Patch (against debian version 1.12.3-1): --- camel/providers/imap/camel-imap-store-summary.c.orig 2008-02-04 14:42:58.000000000 +0100 +++ camel/providers/imap/camel-imap-store-summary.c 2008-02-04 14:39:54.000000000 +0100 @@ -335,6 +335,9 @@ pathu8 = camel_imap_store_summary_full_to_path(s, full_name, dir_sep); } + if (!g_ascii_strcasecmp (pathu8, "INBOX")) + pathu8 = "INBOX"; + info = (CamelImapStoreInfo *)camel_store_summary_add_from_path((CamelStoreSummary *)s, pathu8); if (info) { d(printf(" '%s' -> '%s'\n", pathu8, full_name)); b
I have the same problem with Lotus Domino server. Another way to fix that bug would be to store the path in the summary as they are one the server (that is the way its currently done) but then in get_folder_offline do the "Inobx" -> "INBOX" translation *after* we got the CamelStoreInfo out of the summary. I have tested my version of the patch but from a quick look the version from Alexander also looks correct. Apropos, while reviewing Alexder's patch I found that the pathu8 memory is leaked. Note sure which version is better. On a different note: can the Inbox be inside a custom Namespace and this pathu8 be something different then "INBOX" for the Inbox? Index: providers/imap/camel-imap-store.c =================================================================== --- providers/imap/camel-imap-store.c (revision 8637) +++ providers/imap/camel-imap-store.c (working copy) @@ -2085,13 +2085,13 @@ CamelFolder *new_folder = NULL; CamelStoreInfo *si; - if (!g_ascii_strcasecmp (folder_name, "INBOX")) - folder_name = "INBOX"; - si = camel_store_summary_path((CamelStoreSummary *)imap_store->summary, folder_name); if (si) { char *folder_dir, *storage_path; + if (!g_ascii_strcasecmp (folder_name, "INBOX")) + folder_name = "INBOX"; + storage_path = g_strdup_printf("%s/folders", imap_store->storage_path); folder_dir = imap_path_to_physical (storage_path, folder_name); g_free(storage_path);
I think I'd prefer the latter patch, but I don't have a strong opinion. One request though. Can you please add a comment explaining why we need this special case? Camel is chock full of undocumented special cases like this and all it takes is some new maintainer (like me) to come along and naively think "Why is it doing that? That's dumb. [DELETE]" to break everything.
Created attachment 109373 [details] [review] Patch with documentation Matthew you are totally right. I hope the added documentation bit makes sense. Thanks
And while I am at it, here is the patch for the small leak: Index: providers/imap/camel-imap-store-summary.c =================================================================== --- providers/imap/camel-imap-store-summary.c (revision 8637) +++ providers/imap/camel-imap-store-summary.c (working copy) @@ -344,6 +344,7 @@ } else d(printf(" failed\n")); + g_free (pathu8); return info; }
Gicmo, commit both I would say to stable and trunk :)
Thanks Sri, committed to both branches.
> I think I'd prefer the latter patch, but I don't have a strong opinion. Actually I think it would be (have been) better to always use "INBOX". As far as I know, the IMAP RFCs do not state that server should always use the same capitalization for "INBOX" ;-) But it might happen if the email provider (or, more likely, university institute) changes the server software. This is not common, but why not avoid the potential problem. If the summary is changed, on the other hand, it will break present account setups. Maybe a small script could fix the existing account setups.