GNOME Bugzilla – Bug 647816
Moving folder hierarchy causes error
Last modified: 2011-05-09 16:30:16 UTC
I am attempting to rename/move a folder which has children. When I rename it by right-clicking to change its name, camel_store_rename_folder() gets called *once* from evo/mail/em-folder-tree.c::folder_tree_cell_edited_cb(). And Evolution manages to cope with the concept that the child folders have *also* changed their full_name. All is well. But when I rename it by dragging it to a new parent, evo/mail/em-folder-utils.c::emft_copy_folders__exec first calls camel_store_rename_folder() for the folder I moved, and *then* it calls it again for all the children. And when it calls it for the children it gets an error, because the child *already* got renamed automatically when it followed its parent to the new home. For example, in the 'On This Computer' local mail store, create a folder named 'foo' and a subfolder 'foo/bar'. Now drag 'foo' to become a child of the Inbox. See the error "Could not rename 'foo/bar' to Inbox/foo/bar: No such file or directory". Also happens with imapx and EWS back ends. I tried a simple approach of removing CAMEL_STORE_FOLDER_INFO_RECURSIVE from the flags in emft_copy_folders__exec(), but that seems to make no difference at all.
'On This Computer' doesn't support subfolders under Inbox as Evolution has been moved to maildir, bug 536240 one more similar issue with rename folder bug 633162 but both the bugs are valid against Evolution 3.0, not sure about 2.32.x
This patch "fixes" it. I think it's probably the right solution, if the 'WTF' can be solved... is that just a backend bug? --- a/mail/em-folder-utils.c +++ b/mail/em-folder-utils.c @@ -97,13 +97,16 @@ emft_copy_folders__desc (struct _EMCopyFolders *m, gint complete) static void emft_copy_folders__exec (struct _EMCopyFolders *m) { - guint32 flags = CAMEL_STORE_FOLDER_INFO_FAST | CAMEL_STORE_FOLDER_INFO_RECURSIVE | CAMEL_STORE_FOLDER_INFO_SUBSCRIBED; + guint32 flags = CAMEL_STORE_FOLDER_INFO_FAST | CAMEL_STORE_FOLDER_INFO_SUBSCRIBED; GList *pending = NULL, *deleting = NULL, *l; GString *fromname, *toname; CamelFolderInfo *fi; const gchar *tmp; gint fromlen; + if (!m->delete) + flags |= CAMEL_STORE_FOLDER_INFO_RECURSIVE; + fi = camel_store_get_folder_info ( m->fromstore, m->frombase, flags, &m->base.error); if (fi == NULL) @@ -131,8 +134,14 @@ emft_copy_folders__exec (struct _EMCopyFolders *m) GPtrArray *uids; gint deleted = 0; - if (info->child) - pending = g_list_append (pending, info->child); + if (info->child) { + /* XX WTF? */ + if (flags & CAMEL_STORE_FOLDER_INFO_RECURSIVE) + pending = g_list_append (pending, info->child); + else { + printf("non-recursive fetch had child? wtf?\n"); + } + } if (m->tobase[0]) g_string_printf (toname, "%s/%s", m->tobase, info->full_name + fromlen);
Commit d44fb9e in evo head.
Commit 9cde869a in gnome-3-0 Commit b63b75b1 in gnome-2-32
(In reply to comment #2) > + /* XX WTF? */ > ... > + printf("non-recursive fetch had child? wtf?\n"); Why the hell are you adding this crap into evolution code, please?!!! If you like it in evo-ews then that's only your opinion and your choice, but if you are committing (especially *on your own*) into evolution code, then be so kind and do not add such crap into sources. I thought you got me when I told you about your vocabulary on evo IRC channel about a month ago, but you obviously didn't.
Ha, you are lucky, the actual commit in sources doesn't contain that :) I expected you are adding to bugzilla the same code which will be committed, and you'll indicate if you commit anything else. I use to do that this way. Anyway, the committed change is "clean".