User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20060124 Firefox/184.108.40.206
Build Identifier: Mozilla/Thunderbird version 1.0.7 (20050923)
I know the filters exist. Alt-T+R runs them and sorts my email.
Alt-T+F brings up the filters window, but none are listed.
I'd like to know where they actually live so I can copy them out
and re-install (1.5 this time) and re-add these filters. I do
not know how I got into this state. Obviously, it is somehow
possible. If I can tar up the state information for you-all (or
you-whomever) to inspect, I'd be glad to try to help.
Steps to Reproduce:
4. knew. :-}
I've prioritized as "Major" since the filtering is misbehaving badly
anyway and I would like to upgrade my version. (By "misbehaving" I
mean that I've never gotten my filters to work on incoming mail from
any email source (I have three). I have always had to run the filters
manually with the Alt-T+R key sequence once the messages are pulled
into my Inbox box.)
Maybe related to Core bug 267991 comment 2?
If it is related, then the speculative reason is different.
I am using a fairly small fraction of the 120 GB of disk.
I also cannot locate any msgFilterRules.dat file. However,
Thunderbird still has the rules hidden away somewhere. Where?
Maybe I can yank it out of some binary file.....
BTW, I have *successfully* added new filter rules that work.
However, they do not show up in the filter list after a stop
and restart. (They show for the current session only.)
SO: it *may* be related, but I have some symptoms that are not
mentioned in that bug report.
Well, gee whiz. I finished reading some more about the bug and I _DID_
find the msgFilterRules.dat file. It has _some_ (but not all) of my
filters in it. In fact, it has the filters I added since it first
disappeared! But, not the filters from before, even though all the
filters are working. I did not find it before because I was not looking
in the mail data hierarchy. So, my problem may be related to having
redirected the mail data to ~/Mail???
(In reply to comment #3)
> I _DID_ find the msgFilterRules.dat file.
> It has _some_ (but not all) of my filters in it. In fact, it has the filters I
> added since it first disappeared! But, not the filters from before, even though
> all the filters are working.
Both account and Global Inbox("Local Folders" usually) has msgFilterRules.dat file, if Global Inbox is used.
See Thunderbird FAQ of MozillaZine knowledge base.
When Tb 1.0.x, as FAQ says, one for account is executed on download, and one for "Global Inbox" is executed when manual "Run filter on folder" for the "Global Inbox", but when Tb 1.5, it's changed and both are executed on mail download(See Release Notes of Tb 1.5 and the FAQ).
Anyway, the current state is that there are a number of invisible filters
that are operational, but I cannot find them for editing or viewing.
It would be nice if I could so I would not have to re-invent them all when
I upgrade to the next Thunderbird. Thanks.
Please see bug 362539 comment 6 for a possible approach to a circumvention (and explanation of?) this bug, found by PBilodeau.
It's a different problem. I generally power down my system after being on
for a few hours, so there should not have been piles of xxxx-nnnn.tmp files
lying around in my $TMPDIR. In any event, in the intervening couple of years
I finally updated to an x86-64 system and I've recreated all of my filter
rules by hand. I do hope that won't be necessary again. :( Thanks! :)
So, it seems to work for me now.
The name (In reply to comment #7)
> It's a different problem. I generally power down my system after being on
> for a few hours, so there should not have been piles of xxxx-nnnn.tmp files
> lying around in my $TMPDIR. In any event, in the intervening couple of years
> I finally updated to an x86-64 system and I've recreated all of my filter
> rules by hand. I do hope that won't be necessary again. :( Thanks! :)
> So, it seems to work for me now.
1) As stated in the post quoted in that bug report, the names of the files are of the form tmprules-xxxx.dat, not xxxx-nnnn.tmp.
2) The description there did not indicate that those files would be automatically deleted on reload. The point was the rate at which they are generated while the filters dialogue is open, that they accumulate and that there is a limit of about 9999 after which the bug symptoms manifest.
3) "there should not have been.." is an assertion which we cannot evaluate at this point. Given that and the other two points, I do not feel convinced that this could not have been the same problem.
4) Given that, of the three bug reports on what may be the same problem or closely related ones this is the only one actually opened for Linux platform and at least one other person may well have encountered the same problem on Linux, it may be rather inappropriate to close it simply because, with a change of configuration, it has gone away for you. It does look quite possible that this bug is well defined and still exists in TB and that means the report should not be closed without a solution which applies to all potential victims.