Closed Bug 450424 Opened 11 years ago Closed 9 years ago

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.

Categories

(MailNews Core :: Filters, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: World, Unassigned)

References

Details

(Keywords: dataloss)

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
This is spin-off of Bug 448374 Comment #1.
Per bug 427865, this also occurs if the tmprules.dat is in a temporary folder.
Duplicate of this bug: 427865
This is probably an easy fix, so I'll try to get to it.
Assignee: nobody → kent
Status: NEW → ASSIGNED
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.
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.
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.
I am using version 2.0.023 (20090812).  Kathy
Assignee: kent → nobody
Status: ASSIGNED → NEW
WFM per comment #7
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Severity: normal → critical
Keywords: dataloss
Duplicate of this bug: 368156
You need to log in before you can comment on or make changes to this bug.