GNOME Bugzilla – Bug 576953
unread vfolders STILL not working in 2.28.1
Last modified: 2010-03-26 15:45:32 UTC
I am running 2.26.0 and unread vfolders are STILL NOT WORKING! I have messages in one of the Inboxes that are a member of my Unread vfolder and there are still, messages which are unread in the inbox that are not being displayed in the vfolder. When is this stuff going to be fixed already? This is the second stable release with broken vfolders. How many more stable releases is it going to take just to make it work bug free, and then how many more stable releases after that is it going to get to be back in feature parity (i.e. vfolders of vfolders) with what was working and available prior to all of this breakage? Seriously, when will this new vfolder stuff be deemed a complete failure and the old code restored and whatever problems existed with it revisited in a different manner than what we have today? Vfolders used to work perfectly well for me before all of this rewrite carnage.
This is not a blocker at all - see the definition of blocker, and it's not udeful to file duplicates just because of being frustrated.
(In reply to comment #1) > This is not a blocker at all - see the definition of blocker, I don't know why a feature that has been broken for two stable releases should not be considered a blocker for the next release. Obviously its being classified as less than a blocker is having a negative impact on it getting fixed and the problems are lingering on and on. > and it's not > udeful to file duplicates just because of being frustrated. If there wasn't such a pile of bugs against vfolders to try to wade through and figure out which bug describes my failure, I might not be so discouraged into trying to actually do it. But at this point, it's such a quagmire that about the only person/people that know what is which are the people/person actually (supposed to be) working this pile of problems.
So is this bug a duplicate of some other existing bug (that describes that 2.26 still does not show all messages in an unread vfolder) or not? If there is an active bug for that problem, I'd like to get on it and follow it along. If there is not, don't you think some work should be done to fix this problem as it's been outstanding now for two stable releases? No comment or assignment, etc. with this bug can only leave me wondering if this issue (unread vfolders) is just getting swept aside or if it's actively being worked as a priority. I was just going through one of the source folders for my unread vfolder and noticed that still/again, there are messages from the last few days that are unread and simply just not being shown in the vfolder.
Just to say: In my case this bug is essential. The organisation of my job is reflected by the names, numbers and hierarchy of vfolders in evolution. As long as this bug exists evolution is useless for me.
OK. This bug is still present in 2.28.1. I have a specific use-case that demonstrates it. During the deadlock that I am seeing in bug 606813, any new messages that arrive while Evo is deadlocked will not be displayed in my Unread folder(s) when I restart Evolution to recover from the deadlock. That is, the Unread folder has the same messages in it that it had when it deadlocked, plus any new that arrived since it was restarted (i.e. to recover from the deadlock). Any intervening messages will only be in the original/source inboxes. So, if you can reproduce bug 606813, then you can reproduce this vfolders bug.
In fact it is even simpler than my previous reproducer. Simply stop evolution for a while -- overnight did it for me last night. I started it up this morning and all messages which had arrived into my (imap) INBOXes while evolution was not running were not in the unread vfolder when it was started back up again. Messages that arrived after evolution was running again were in the vfolders. So it seems like messages have to actually arrive while evolution is running to get considered for vfolders. I'm really not sure how a message that arrives into an (imap) INBOX while evolution is running is materially different from a message that was in the (imap) INBOX while evolution was not running and of course is still there when it restarts. I would think those to messages are effectively the same from evolution's (or any imap client) point of view.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 569576 ***