450424 - Update of message filter is always lost after restart of Tb/Seamonkey, if garbage of tmprules.dat remained in mail directory(at where msgFilterRules.dat is held), because update of msgFilterRules.dat fails due to the garbage of tmprules.dat.

Status: RESOLVED WORKSFORME

(MailNews Core :: Filters, defect)

Description

[WADA:World Anti-bad-Duping Agency]

Problem reported to a forum in Japan.

Update of message filter is always lost after restart of Tb/Seamonkey, if garbage of tmprules.dat remained in mail directory(at where msgFilterRules.dat is held), because update of msgFilterRules.dat fails due to the garbage of tmprules.dat.

Problem was recreated with Tb latest-trunk on MS Win-XP SP3.

(A) tmprules.dat exists, msgFilterRules.dat exists
msgFilterRules.dat is read, filters in it are usable, and add/delete/modify is effective until restart. But unable to update msgFilterRules.dat, thus all update is lost after restart.
Exeption is displayed in Error Console when tries to save msgFilterRules.dat.

(B) tmprules.dat exists, msgFilterRules.dat doesn't exists
"Go Filter Rules panel and close panel" creates null msgFilterRules.dat.
After that, same as (A). In this case, all filter is lost after restart, because of null msgFilterRules.dat.

When "tmprules.dat" remained, mail folder of "tmprules.dat" appears in folder pane(this is design/spec of Tb). 

Garbages of tmprules.dat can occur, very rare though :
(1) Add filter/delete/modify of filter rule
(2) Genarate updated data in %temp%\tmprules.dat(or tmprules-NNNN.dat)
(3) Copy it to tmprules.dat under mail directory(msgFilterRules.dat is held)
==> Crash at here(msgFilterRules.dat is alive)   
(4) Delete msgFilterRules.dat
==> Crash at here(msgFilterRules.dat is lost)
(5) Rename tmprules.dat to msgFilterRules.dat

Comment 1

[WADA:World Anti-bad-Duping Agency]

This is spin-off of Bug 448374 Comment #1.

Comment 2

[Kent James (:rkent)]

Per bug 427865, this also occurs if the tmprules.dat is in a temporary folder.

Comment 4

[Kent James (:rkent)]

This is probably an easy fix, so I'll try to get to it.

Comment 5

[David :Bienvenu]

We're looking at doing a build 2 of rc1, so if this turns out to be an easy fix, with a patch by tomorrow, I'd consider taking it.

Comment 6

[Kent James (:rkent)]

With bienvenu's encouragement, I looked at this immediately.

I now believe this is primarily a TB 2.0 branch problem, in spite of WADA's "Problem was recreated with Tb latest-trunk" from comment 0. WADA, you have been all over this issue for years, so correct me if I am wrong, but here's the history as I see it:

Bug 375292 landed on branch and trunk in 2008-01-10 and 2008-01-17  On trunk, issues started being noticed right away, that were solved by bug 413680 on 2008-01-31  That bug never landed on branch, but since then there are no references at all to tmprules.dat in trunk. I am also unable to reproduce this bug on revent TB nightlies. If we weren't so close to release of TB 3, I would be looking at landing bug 413680 on the TB 2.0 branch.

When I duped this bug to bug 427865, I was assuming that this bug had been demonstrated on recent TB 3.0 versions, but as I look through the history that is not as clear (except for the aforementioned comment 0).

So at this point, I am unable to do anything without STR on trunk. WADA, if you can provide those, then I'll be happy to try to fix this.

Comment 7

[David :Bienvenu]

Thx for looking, Kent. I think you're right - I looked at the code and the trunk/3.0 is using NS_NewSafeLocalFileOutputStream instead of a temp file, so it should be unaffected by a tmp filter file.

Comment 8

[Kathy Hickerson]

I am using version 2.0.023 (20090812).  Kathy

Comment 9

[WADA:World Anti-bad-Duping Agency]

WFM per comment #7