GNOME Bugzilla – Bug 637412
Folder list has an empty entry in it
Last modified: 2013-02-01 13:22:07 UTC
Created attachment 176547 [details] Screenshot of "invisible folder" For reasons unknown to me, Evolution has developed an empty entry in the folder list. There is a row in the list of folders associated with an imapx account of mine that has no folder icon, nor any accompanying text. See the attached screenshot: the line above the "gerbv-devel" folder is selectable. When I select it nothing exciting happens -- the mail pane becomes empty. This empty line seems to move around in the folder list as I move from folder to folder.
Thanks for a bug report. I thought this is finally fixed with changes from bug #604306.
rds204: Any chance to retest this in Evolution 3.0.x (as bug 604306 was fixed in that version)?
I've just reproduced the same bug with Evo 3.0.3, so it's not fixed... If you want to debug it, please ask now, as I suspect it might disappear, just like other Evo weird issues.
Hrm, I hoped we have this finally done :( Looking into the code there is no debugging for this, the only way would be to provide a debugging patch, with which applied it may, hopefully, discovered why there was added or left an empty node. Would you be able to compile evolution yourself (not so easy), or ask your distribution maintainer to build a test package with some (yet to be done) test patch applied, please? By the way, what is your distribution, please?
I would build Evo using jhbuild, but sadly for now I've not enough disk space due to a broken partition I'm waiting to fix. So I can't really try ATM. I'm on Fedora 15, but I don't know whether a service allows building custom packages (OBS?). Or maybe you can build one for me? :-p
Here [1] you are :) I hope I covered all relevant places. Just run evolution from a console like this: $ evolution &>log.txt and make sure you'll see the issue inside the folder tree. Then close evolution and observe the log.txt whether it'll not contain anything you would not like to share publicly. it exposes your folder structure and account names, it may not contain passwords, but check the content just to be sure. If you do not want to share it here, then feel free to send it only to me, on the bugzilla email, only name the bug in the subject, otherwise I would overlook it under the spam folder. Thanks in advance. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3441174
Created attachment 199365 [details] Log with patched Evo Hey, great! For a few seconds I thought I would sound silly, because the empty folder just disappeared a few hours ago: after I started Evo while being offline, a few subscribed folders were unchecked (I had to re-add them manually), and that fixed the problem. So I tried very hard to reproduce the bug, and actually after moving a test folder about ten times to and from a subfolder, and then restarting Evo, the empty folder reappeared. It was visible before restarting, FWIW. The critical point is probably that you need a 3-level hierarchy; mine is: INBOX |- Lab |- Univ |- [EMPTY] |- test
Hm, there seem to be another bug, because the 'test' folder from above no longer existed after restarting Evo, and I was back to the original hierarchy, with the original empty folder. Thus, the log doesn't correspond to the hierarchy represented above, but to: INBOX |- Lab |- [EMPTY] |- Univ The interesting lines in the log seem to be: em_folder_tree_model_set_folder_info: adding node for 'INBOX/Lab' em_folder_tree_model_set_folder_info: adding node for 'INBOX/Lab/Univ' em_folder_tree_model_set_folder_info: adding node for 'INBOX/Lab/Univ' That is, it looks like 'Univ' is duplicated, the first one corresponding to the empty folder.
Thanks for the update. I agree that this one does the trouble. Here [1] is another go on the debug package, but it only workarounds main issue, that the provider returned one folder twice in the folder info. Is it IMAP+ for you too, or IMAP or any other provider, please? In case it's IMAP+ please run evolution from console like this: $ CAMEL_DEBUG=imapx evolution &>log.txt it will expose all the communication with the server (including username and password), but I'm interested in the LIST/LSUB commands only, which will show how was the hierarchy returned from the server. I would like ot know whether this is a bug in the IMAP(+) code or on the server. Thanks in advance. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3443537
Created attachment 199448 [details] Log with CAMEL_DEBUG=imapx The new package indeed makes the empty folder go away. I'm attaching the log of before I installed that package, but I don't think it matters. And yes, I'm using IMAPX. What is very strange is that in the log I'm seeing the hierarchy I first described, which doesn't match what I see in the GUI
Thanks for the update. Checking the code I guess the IMAPx store summary has the folder stored twice, which does all the confusion around, like generating incorrect folder-info structures.I do not know when and how this could change, but as a test, could you move away (not delete) ~/.local/share/evolution/mail/imapx/<this-account> folder while evolution being off, and then start it, thus the imapx will reload everything from scratch from the server, please? You can keep the patched evolution and see in debug prints whether the imapx returned the same folder twice or not (if it will see the same folder twie, then it'll print "skipped node for '<folder-name>', already known" message on the console.
OK, the reloading fixes it: the error "skipped node for '<folder-name>', already known" doesn't appear in the logs, and the folder is only added once.
Good, thanks for the update. I guess we can close this as an issue with underlying data then, right? The most I can add some checking similar to the one in the evolution test package and print a warning when anything like this happens. rds204, could you check the local cache removal as is suggested in comment #11 too, please? Just to confirm it's the same issue for you like for Milan (the other one than me ;) )
(In reply to comment #13) > I guess we can close this as an issue with underlying data then, right? I don't really understand. To me, it seems moving folders from Evo can create corruption in the database which is not present on the server. So that would require a fix to prevent the corruption from happening, isn't it? Or am I missing something?
(In reply to comment #14) > (In reply to comment #13) > > I guess we can close this as an issue with underlying data then, right? > I don't really understand. To me, it seems moving folders from Evo can create > corruption in the database which is not present on the server. So that would > require a fix to prevent the corruption from happening, isn't it? Right, if there is a reproducer to get the underlying data corrupted, by some kind of user interaction in GUI, like the folder moving you mentioned, then the fix is to avoid this corruption. I thought there is no known reproducer at the moment.
Created attachment 199561 [details] Log when moving 'test' folder all over the place Like I said, I'm able to reproduce the bug by just moving a folder many times in a row. Then, when restarting only, the empty folder appeared. Now, with the patched Evo, the empty folder doesn't appear, but the moved folder appears in its old location rather than its new one; this is fixed if I restart Evo twice. Attached is the relevant log of the first session, where I move the folder many times. There are warnings that can explain the problem there
Created attachment 199562 [details] Log when restarting Evo for the first time This log shows an inconsistency in the place where 'test' is: [imapx:?] find_full: comparing namespace 'INBOX' to name 'INBOX.Lab.test' [...] em_folder_tree_model_set_folder_info: adding node for 'INBOX/Lab/test'
Is this still an issue in GNOME/Evolution 3.4.x?
I haven't seen an empty entry in a long time. I'm running 3.4.2.
Not seen it for a while either, I'm running 3.6.2 now. Let's hope it's now fixed...
Indeed. I no longer have this issue (running 3.4.4).