Tony Mechelynck [:tonymec] Reporter
	Description • 18 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070130 BonEcho/2.0.0.2pre
Build Identifier: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070130 Thunderbird/2.0pre" - Build ID: 2007013003

On auto-compact (even with confirm), but *not* on manual compact, all Junk massages lose their "junk" status.

Reproducible: Always

Steps to Reproduce:
1. Make sure that Junk detection is enabled.
2. Make sure that there are one or more messages, marked as junk, in your Junk folder.
3. Make sure that auto-compact is enabled. (Setting a low threshold may make the bug manifest itself earlier.) -- Disabling _silent_ auto-compact will trigger a confirmation popup just before the bug happens.
4. Work until Thunderbird (or SeaMonkey) asks if you want to compact folders.
5. Click OK.

Actual Results:  
All messages in Junk folder are now marked as "not junk".


Expected Results:  
Junk should remain marked as junk, regardless of any compacting.


Additional info:
This is a regression to bug 258731, except that the latter was for W2K and I'm seeing this on Linux.

	Tony Mechelynck [:tonymec] Reporter
	Comment 1 • 18 years ago

Bug seems to have disappeared "not later" than today:

"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070202 Thunderbird/2.0pre" - Build ID: 2007020204

If someone still sees it (on current Tb 2.0pre nightlies), please say so, otherwise I'll resolve it WORKSFORME.

	Tony Mechelynck [:tonymec] Reporter
	Comment 2 • 18 years ago

"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070204 Thunderbird/2.0pre" - Build ID: 2007020405

Ah la la, I see it again: my Junk folder now again has unmarked mail. Auto-compact without confirm? Restart? If I could, I would remove the "Reproducible: Always" from comment #0.

	WADA:World Anti-bad-Duping Agency
	Comment 3 • 17 years ago

(In reply to comment #0)
> On auto-compact (even with confirm), but *not* on manual compact, all Junk
> massages lose their "junk" status.

Really "when compact folder" and "when automatic compact"?
Is there any evidence of "when automatic compact" such as log or trace?

Properties/"Rebuild Index"(new feature from Tb 2.0) clears Junk status mark.
(this is already reported problem, and enhancement request of "keep Junk status in mail header" is also requested.)
And, if "rebuild index" of Junk folder occurs by some reasons (msf corruption due to too large file size etc. is cause in many cases), unmarks of Junk will occur. 
It is the case, isn't it? 

	Tony Mechelynck [:tonymec] Reporter
	Comment 4 • 17 years ago

In reply to comment #3
That could be a reason, but I haven't noticed this bug recently (well, let's say at least since the summer holidays), either because I disabled auto-compact and tried to avoid compacting manually while Tb was busy reading mail, or more recently (after I re-enabled it a couple of days ago) because I don't keep mail for any long time spans in the Junk folder (nor, for that matter, in the Inbox). Also, now that I've re-enabled auto-compact (but only when saving 1MB or more, which is 10 times the default), it asks for permission before doing it. But it's only very recently that I've re-enabled auto-compact (having forgotten about this problem) and also increased the threshold. I'm not laying bets (yet) that it's cured in my current Tb build, viz., "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12pre) Gecko/20080131 Thunderbird/2.0.0.12pre" (2008013104)

Finally, I've noticed a noticeable decrease of my spam input recently: a few months ago, I could get hundreds of spam emails a day; nowadays I get maybe an order of magnitude fewer of them. Could it be that SpamCop spam reporting has resulted in the worst spammers being banned from all ISPs? I'm taking no bets ;-) .

	Tony Mechelynck [:tonymec] Reporter
	Comment 5 • 17 years ago

Now that I think of it, another reason why I haven't noticed it recently could have been for failing to pay attention to the flame in the Junk folder (where everything is supposed to be junk isn't it?) Sometimes I check it in Trash, where I have noticed that a huge majority of the mail (nowadays) is already-read mail from the Bugzilla daemon.

	Michael Davis
	Comment 6 • 17 years ago

I encountered this problem on version 2.0.0.12 (20080213) (XP Pro). The junk status was removed when the junk folder was automatically compacted. Changing the compact threshold to a high value (i.e. 10000) causes the bug to have less of an impact. (also see bug 354662).

	Roby Van Hoye
	Comment 7 • 16 years ago

I seem to have the same issue. (version 2.0.0.19 (20081209), Windows XP Pro)

My view on the problem is that it only happens when auto-compact is running and you mark something as Junk in the Inbox. The message gets marked Junk as expected, but it fails to (automatically) move the message from Inbox to the Junk folder because of the compacting routines running. As from that moment on, all messages in the Junk folder have lost there 'Junk' status. 
I hadn't yet been able to 'force' this issue manually though, but maybe that's because it only happens when the compacting is triggered automatically as stated above.

	Ekhart
	Comment 8 • 15 years ago

I can confirm that Tb 2.0.0.21 (20090302) on POP3 has periodically stopped marking spam as junk but still moves it automatically to junk folder. Tb does add junk flag when i manually mark spam as junk (contrary to what i just now reported in closed similar bugs because i was confused), but it suddenly removes these flags and those on all old ones in the junk folder that were there before. It even removes flags (not immediately) of messages that i manually remarked as junk while in the junk folder. Interestingly, the problem does not exist in other accounts. 

At least in two cases, automatic compact was perhaps already running when i marked something as junk when this occurred, but i'm not sure both of these conditions were always fulfilled. 

Tb often doesn't indicate when compact is running. Especially combined with the fact that Tb doesn't prevent access to folders being compacted seems to be the main reason for the perhaps most serious bugs causing data loss like bug 493065 and bug 482486.

Has a separate bug report been opened dealing with TB's inability to prevent access to folders during compact?

Has a separate bug report been opened dealing with TB's inability to always and reliably show when it's compacting? It seems this is especially true when one clicks on a different account's folder to let Tb compact in peace. As soon as you click on a different folder, the green progress indicator usually but not always disappears.

	WADA:World Anti-bad-Duping Agency
	Comment 9 • 15 years ago

To Michael Davis(Comment #6), Roby Van Hoye(Comment #7), Ekhart(Comment #8):

Original phenomenon in Comment #0 is;
  (a) Junk mark of all mails in Junk folder is lost.
  (b) It looks "one time failure".
And, (a) can easily be observed by manual "Rebuild Index" of local Junk folder with Seamonkey 1.1.15(same code level as Tb 2.0.0.21 is used).

(Q1) Is your problem really same as the original problem? (all mails in Junk?) 
(Q2) Really produced by (auto-)compact?

If loss of Junk mark of partial mails(newly downloaded mails), and if "compact folder" is a suspect, it may be "Junk Mark" version of Bug 495666.
If "compact folder" is a suspect, see bug 498274 comment #2 and check whether "compact folder" is one of culprits or not first.

To Tony Mechelynck(bug opener):

Was you problem really produced by auto-compact itself?

You probably didn't enable auto-compact, then mail folder size was probably very big. It tends to produce "outdated .msf" condition which will force internal rebuild-index upon explicit folder open(left click of mail folder). However, "Junk move" doesn't open Junk folder explicitly, so internal rebuild-index is not invoked by "Junk Move" even if "outdated .msf" condition exists. In contrast to it, "compact folder" including auto-compact opens mail folder internally.
I guess your case was next, because comment #0 looks "one time failure".
  - "outdated .msf" condition existed on Junk folder, and internal rebuild-index
    was invoked by Junk folder open by auto-compact.

	WADA:World Anti-bad-Duping Agency
	Comment 10 • 15 years ago

FYI.
"Loss of Junk mark by rebuild-index" is already fixed by Bug 449768(fixed by 3.0b1).

	WADA:World Anti-bad-Duping Agency
	Comment 11 • 15 years ago

To Michael Davis(Comment #6), Roby Van Hoye(Comment #7), Ekhart(Comment #8):

Do you run software which reads Tb's mail folder files while Tb is running?
If yes, and if "loss of Junk mark of all mails in Junk folder", Bug 498814 may be culprit. If auto-compact is interfered by external software, Bug 498814 can produce "no .msf file" condition, and "no .msf file" condition will invoke internal rebuild-index upon next folder open by folder click, auto-compact etc.

	Roby Van Hoye
	Comment 12 • 15 years ago

Well,I must admit that it annoyed me that much that I switched off automatic-compacting, and the bug hasn't occurred ever since. So I would state that this is either due to the automatic-compacting or because it was fixed in the meanwhile. (currently running version 2.0.0.21 (20090302)).

Thanks for looking into this !

	Anil
	Comment 13 • 15 years ago

I have confirmed that this bug exists in Thunderbird 2.0.0.23.

With auto compact set at whatever size you want, when auto compacting is triggered, it will perform the compacting of all you folders, including the junk folder.  When it compacts the junk folder, the status of all of the messages that were previously marked as junk in the junk folder, are magically no longer set as junk even though their status as junk should not have been altered.

	David :Bienvenu
	Comment 14 • 15 years ago

I suspect this is fixed in TB 3.0 beta builds (e.g., b3)

	Wayne Mery (:wsmwk)
	Comment 15 • 15 years ago

kent, do you recall in which bug you (or someone else) fixed this?

	Kent James (:rkent)
	Comment 16 • 15 years ago

I did not find any specific bug that fixed this. The database preservation work that I did was mostly associated with copy actions. It would be good to verify whether the issue here still exists.

	Roby Van Hoye
	Comment 17 • 15 years ago

First off : the bug never happened again, probably because I switched off auto-compacting (see above). Additionally, my ISP seems to have installed a "decent" SPAM-filter because I hardly get any spam these days.

Nevertheless, in view of the mail I received from bugzilla I upgraded to v3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1) some days ago.

I've switched on Auto-compacting and will keep an eye on it, but so far the situation hasn't presented itself yet. I'll keep this place updated if it should.

	Tony Mechelynck [:tonymec] Reporter
	Comment 18 • 15 years ago

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100212 SeaMonkey/2.0.4pre - Build ID: 20100212005047

I haven't experienced that bug recently. Currently, whenever there is 512K or more of "reclaimable message space" SeaMonkey asks me if I'll let it compact folders, and usually I click Yes (or is it "OK"?). AFAICT, messages in Junk remain Junk, even when Junk is one of the folders where the messages get moved about by the compacting process.

On rereading the above comments, and in particular comment #4 which I wrote over a year ago, I think I can safely say that I haven't seen this bug in more than a year, perhaps even a year and a half, so I'm setting it WFM (not FIXED since apparently no one has the least idea where or how it got fixed). If anyone gets bitten by it while using a _current_ build of Thunderbird or SeaMonkey, feel free to REOPEN.

	Tony Mechelynck [:tonymec] Reporter
	Comment 19 • 15 years ago

Oops, this is a moz-1.8 bug so whatever I say about comm-1.9.1 is irrelevant. Well, I guess it will be RESOLVED EXPIRED or some such once Tb2 and Sm1 will both have reached EOL.

	Wayne Mery (:wsmwk)
	Comment 20 • 15 years ago

(In reply to comment #19)
> Oops, this is a moz-1.8 bug so whatever I say about comm-1.9.1 is irrelevant.
> Well, I guess it will be RESOLVED EXPIRED or some such once Tb2 and Sm1 will
> both have reached EOL.

in that case, perfectly fine to call this WFM, which is status on trunk