GNOME Bugzilla – Bug 593882
Ghost mails seen in Anjal Trash folder
Last modified: 2015-06-22 06:29:22 UTC
Created attachment 142298 [details] screenshot shows a ghost mail in Trash folder This bug appears in Anjal but roots in EDS so I report it here. It was first reported at Moblin Bugzilla: http://bugzilla.moblin.org/show_bug.cgi?id=5819 Build Image(yyyy-mm-dd): anjal git tip, evolution-data-server git tip Bug detailed descriptions(behavior, impact, etc) =========================================================== On my machine there were some ghost mails shown in mail folder tree, but can't be listed in Trash mail view tab, as you can see in the screenshot. There was 1 unread mail in Trash folder but the Trash tab was empty. How camel reached this situation is still unknown. I have used it heavily for some days and saw this occur. Those mails vuids can be seen in './#evolution/Trash' table and they point to undeleted mails in Inbox. They are not deleted, and that's why they are not listed. When camel/camel-vee-folder.c:vee_rebuild_folder() loads cached vFolder, if the current vf is vTrash, it should remove those uids that are undeleted.
Created attachment 142299 [details] [review] BUGFIX-GNOME-Bug-593882-Ghost-mails-seen-in-Anja.patch This is my fix to this bug, please help to review.
Created attachment 142301 [details] [review] Patch: vee_rebuild_folder() code cleanup and adding comments BTW, vee_rebuild_folder() is very long and complex, the comments are sparse, it's very difficult to read. I'm attaching a little patch that tries to improve the readability a little. It doesn't change code behavior but removes a redundant variable and adds some comments. Please review.
Comment on attachment 142301 [details] [review] Patch: vee_rebuild_folder() code cleanup and adding comments Commit to gnome-2-28 branch and master branch.
Comment on attachment 142299 [details] [review] BUGFIX-GNOME-Bug-593882-Ghost-mails-seen-in-Anja.patch This patch breaks abstraction. CamelVeeFolder is the parent of CamelVTrash. YOu cant compare for trash inside of vfolder. It needs to be done better. Do you have any steps to reproduce this?
You are right. Then I think we can move that function into a new procedure vtrash_cleanup_undeleted_mail() to do this.
Created attachment 142391 [details] [review] BUGFIX-GNOME-Bug-593882-Ghost-mails-seen-in-Anjal-v2.patch I've wrote a new API function camel_vtrash_folder_clean() that does the clean up on-demand. I'm not sure if adding a new API for this is OK, please review this v2 patch. It worked in my test and partially fixed this bug. The Trash folder no longer shows ghost mails. The problem remain is that those uids are still in '.#evolution/Trash' table. They should be removed too.
Created attachment 143574 [details] [review] BUGFIX-GNOME-Bug-593882-Ghost-mails-seen-in-Anjal-v3.patch This v3 patch is another slightly improved version over v2. No need to add a new func to API and no change to client programs is needed now. Everything is done automatically when you are getting a vtrash folder. I'm committing this into Moblin so it can get more testing. Please review. Thanks.
Comment on attachment 143574 [details] [review] BUGFIX-GNOME-Bug-593882-Ghost-mails-seen-in-Anjal-v3.patch Yan, my point remains the same. camel_vtrash_folder_clean() can't be called from camel-store.c This is a derived class function. It may not work for other folders. For example, Exchage doesn't even have vtrash. It will crash for them.
Yan, do you have some steps which will reproduce this for me? I want to see how this happens, then it should be easy to fix it for me. I really dont understand the fix :(
(In reply to comment #8) > camel_vtrash_folder_clean() can't be called from camel-store.c This is a > derived class function. It may not work for other folders. For example, Exchage > doesn't even have vtrash. It will crash for them. Can't I call it from camel_store_get_trash() when I know for sure the result is a (CamelVTrashFolder *)? I've sent you a DB that has this issue.
Ping. If this is still needed, it would be good to get it in before the 2.30.2 release...
Yan Li, in the place you're calling it you don't even know that result is non-NULL. If there is _no_ vtrash folder, won't it just crash? But even with that fixed and if you _did_ know that it will always be a CamelVTrashFolder rather than a store-specific CamelFolder subclass, it looks like the wrong approach. Shouldn't you be removing these messages from the vtrash folder at the time they're undeleted? Isn't that how they get _added_ to the folder in the first place -- not by trawling folders, looking for messages with the DELETED flag?
http://bugs.meego.com/show_bug.cgi?id=1846 was caused by this patch and I had to handle it manually. This has to be done via adding base-class function in CamelFolder .
So ... it would be lovely to get this patch into gnome-2-30 & up-stream properly, I was sorry to still see it included as a patch in the 1st round of updates :-) ...
I'm closing this as obsolete, I do not recall seeing miscounts in a Trash folder since at least 3.12.x.