GNOME Bugzilla – Bug 636855
IMAPX folder deletion traversal does not stop
Last modified: 2010-12-14 19:19:34 UTC
Created attachment 176122 [details] Evo folder deletion log with CAMEL_DEBUG=imapx set affected: evolution 2.30.3 / IMAPX provider Cyrus IMAP v2.3.13-kolab-nocaps (probably, others too) Upon deletion of an imapx folder under INBOX/, after deleting the folder, IMAPX continues traversing the folder tree and tries to delete further toplevel folders (i.e. which are at the same hierarchy level as INBOX/). How to reproduce: Create an imap+ (i.e. IMAPX) imap account, then (1) under INBOX, create a new folder, say "INBOX/foo" (2) have another folder at INBOX level, say "bar", so that the setup looks like INBOX INBOX/foo bar ... (3) if your imap server supports it, remove permission to delete "bar" (4) in Evo, right-click on "INBOX/foo" and choose "delete folder" (5) observe how "INBOX/foo" disappears (the CAMEL_DEBUG logs and server logs show that "INBOX/foo" actually gets deleted) (6) observe how "bar" also disappears, and Evo shows an error message telling that it cannot delete "INBOX/foo" (!) because of missing permissions (7) restart Evo, observe that "INBOX/foo" is truly deleted, while "bar" reappears in the folder tree (since it was not really deleted on the server because of missing permissions) I believe that (6) is caused by the fact that CamelExceptions pile up, a problem which has already been resolved in 2.32 and above because of CamelException being rewritten to GError. Why IMAPX does not stop after successful deletion of the folder it was told to delete, I haven't found out yet. Attaching an Evo log with CAMEL_DEBUG=imapx set. Kind regards, Christian
I don't understand remove_folder_rec() (about line 1454 of mail-ops.c) It seems to be deliberately looping, removing all siblings of the folder which it's supposed to be removing. while (fi) { /* delete fi */ fi = fi->next; } What am I missing?
Additional research shows (thanks for your guidance, David) for my case, that for /INBOX/foo, fi->next points to /bar in remove_folder_rec(). Seems remove_folder_rec() should receive a copy of /INBOX/foo's *fi, with fi->next set to NULL (if only *that* folder should be deleted). fi->next pointing to /bar here is somewhat funny, since it does neither provide what remove_folder_rec() seems to expect, nor does it represent the structure of what gets displayed in Evo's folder tree view. Kind regards, Christian
Works fine for me on actual master. Maybe commit 02f2bbd4 or commit 06b16caf or d5e6beaa or maybe within 4c0f7459, I do not know, I only know that it returns correct folder info now, but I believe it didn't for you, in 2.30.