User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:220.127.116.11) Gecko/20091229 Shredder/3.0.1pre I'm sure everyone has seen the (minor) bug where Shredder stops indexing a particular folder, its symptom is that when you click on the folder it displays the top-level menu for the account while it re-indexes it. Mostly its harmless - except that it seems to stop searching happening on that folder ... there appears to be another bug in Junk handling. If Junk folder gets into this state, then the "Automatically delete junk mail older than xx days" setting gets ignored. For example - I just found that I had a couple of Junk folders with multiple thousands of messages in them going back months. I would suggest that in the absence of the indexing bug (don't have a number for it) getting fixed, then whatever does the junk trimming should trigger reindexing the folder if necessary rather than ignoring the folder if indexing is not current. Reproducible: Always
Component: General → Mail Window Front End
QA Contact: general → front-end
turning off indexing avoids the problem? can you list numbered steps to reproduce?
I can't reproduce it reliably because I can't reliably screw up the folder indexing - it happens often, but I haven't figured out how to predictably do it (I presume if that bug was repeatable it would be fixable). The issue is more the side-effects, like screwing up gloda so it doesn't search those folders, and Junk trimming. Thunderbird knows the indexes are out of date - it reindexes when you try and open the folder - I'm suggesting that things like Junk trimming should trigger the reindexing - and doing a search should probably also trigger it for all folders.
> I'm sure everyone has seen the (minor) bug where Shredder stops indexing a > particular folder, its symptom is that when you click on the folder it displays > the top-level menu for the account while it re-indexes it. actually no :) Do you still see this?
Whiteboard: [closeme 2011-02-21]
I'm seeing it at the moment, I have a bunch of screwed up folders (not sure how caused). In fact, the only reason I'm 12 days late responding to that message is because a) I have a filter that moves bugzilla messages to a folder b) that folder had a screwed up index (there is no indication of this) so c) I saw no indication that there were new messages waiting for me. I don't think this is a MINOR bug , I think in effect it means people miss new mail, which is (almost) a data-loss bug. TB knows these folders are hosed, maybe TB should perform a self-check at startup, including repairing or updating any indexes that are not up to date? This of course is part of the general problem of TB of not being tolerant of its own data-inconsitencies. - Mitra
> TB knows these folders are hosed, maybe TB should perform a self-check at startup, including repairing or updating any indexes that are not up to date? why do you think TB knows this? What is your setting for minutes to check new mail?
Summary: Broken indexing causes Junk folder not to self-trim → Broken folder summary .msf causes Junk folder not to self-trim for "Automatically delete junk mail older than xx days"
Whiteboard: [closeme 2011-02-21] → [needs blocking bug][datalossy]
TB knows something because when I go to the folder it displays the top-level menu and then re-indexes i.e. something in the folder is telling TB that the index is bad, but it isn't looking until you go to the folder. Once again I missed this message from you because my "bugzilla" folder didn't indicate there were unread messages in it till just now. I check mail every 2 minutes.
See Bug# 647487 for another problem with "Mark Folders Read" caused by the same indexing bug getting ignored.
(In reply to comment #6) > I check mail every 2 minutes. so this is happening on your inbox? do you have a way to simulate a bad index, or reproduce the conditions that create one?
I don't remember ever seing the bug on the inbox, its always on other random folders, some are the destination of filters, but I've also seen it on random folders that I'm 90% sure aren't being used or touched by anything (except of course searches) I don't have a way to reproduce a bad index, I've almost always got folders that are in the "bad" state, though I have no way to tell which other than to click on each one - and that click causes it to be reindexed. - Mitra
kent, is this impacted by one of the other issues you are researching?
See Also: → bug 647487
(In reply to Wayne Mery (:wsmwk) from comment #10) > kent, is this impacted by one of the other issues you are researching? I really can't give much feedback on this without specifically researching this bug.
You need to log in before you can comment on or make changes to this bug.