User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20060830 Firefox/126.96.36.199 (Debian-1.5.dfsg+188.8.131.52-1) Build Identifier: 184.108.40.206 Junk Mails that are marked and moved to the junk folder seem to loose their junk-status in the junk folder without any special reason. Reproducible: Always Steps to Reproduce: 1.Click on junk mail flag on junk in inbox or junk mail is automatically falgged and in either case is sent to junk mail folder. 2.Junk mail appears in junk mail folder with junk flag set 3.Look in the junk mail folder later Actual Results: The junk flags have disappeared This is similar to bug 297766 except that it affects local folders using POP/SMTP and it is not resolved.
It'd definitely be worth testing to see if this happens in Thunderbird 2 alpha 1 (if this is possible).
I was testing bug 367255 and ran into this, in a test profile, moving from a folder-o-junk in a POP account to a junk folder under Local Folders. The weird thing is, this is like my regular configuration, where practically all my incoming junk is on a POP account and is getting moved to a folder under Local Folders. Both the first and second times I tried this, the junk was moved by (a) configuring Manual Mark *not* to move junk, (b) manually marking the junk, and (c) using Run Junk Mail Controls On Folder. In both cases, the mail that was moved lost its junk status. The third time I tried it, after manually marking the junk, I set the JMC setting such for Manual Mark = Move to Junk Folder (which is my normal configuration), then again selected Run Junk Mail Controls On Folder. This time, the junk status stuck. John Talbut, does that match your experience at all?
Comment 2 was tested with 220.127.116.11. I just tried again using 2b1-0116, and this time the junk status was maintained even with "move on manual mark" turned off.
Using 18.104.22.168 it does not seem to matter how the junk was moved to the junk folder, generally it will still be marked as junk at first. Then, later when I look at the folder all the junk flags have gone. It has just happened.
I encountered this problem on version 22.214.171.124 (20080213) (XP Pro). The junk status was removed when the junk folder was compacted. The workaround was to change the option "Compact folders when it will save over" to a much higher KB (i.e. 10000). The status change rarely happens and the junk folder is still compacted periodically.
I encounter this problem too on TB3 beta. In my case 'losing the junk status' does not seems to relate to compacting the folders, because I have autocompacting turned off. (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090116 Shredder/3.0b2pre)
(In reply to comment #0) > Build Identifier: 126.96.36.199 > Reproducible: Always >(snip) > Steps to Reproduce: >(snip) > 2.Junk mail appears in junk mail folder with junk flag set > 3.Look in the junk mail folder later > Actual Results: > The junk flags have disappeared I can say nothing about what happend on you. But if it's assumed that internal "Rebuild Index" has been invoked, I think phenomenon can be explained. (a) If crash/freeze etc. occurs during update of Junk folder, "Rebuild Index" of Junk folder can occur. (b) If "Junk Purge" by retention policy etc. is enabled, and if mail.prompt_purge_threshhold=true and mail.purge.ask=false(user requested 'not ask anymore' in the past), "auto compaction" is silently kicked internally. This can produces contention with other operations(move by Junk/message filter, purge by retention policy, ...). And the contention can produce situation with which internal "Rebuild Index" will be invoked. I think Bug 449768 is effective in such cases, although though Bug 449768 itself is enhancement rquest for manual "Rebuild Index". > Bug 449768 Reindexing should save message metadata (junk-related, tags, etc.) (In reply to comment #6) > I encounter this problem too on TB3 beta. > In my case 'losing the junk status' does not seems to relate to compacting the folders, because I have autocompacting turned off. Tb trunk has Bug 472446, Bug 471682, Bug 471130. Even after fix of Bug 449768, ".msf" can be corrupted. Valery Kondakoff, watch these bugs, please.
Please, take a look at this (https://bugzilla.mozilla.org/show_bug.cgi?id=471503) bug. It seems it is related to this problem someway...
(In reply to comment #9) > *** This bug has been marked as a duplicate of bug 471682 *** To Kent James: Original problem is report on Tb 1.5. Really DUP of Bug 471682? Bug 471682 really existed in Tb 1.5 era? (I absolutely agree with you on that "internal rebuild index with Tb trunk" can be invoked by Bug 471682 or some bugs around it.)
The original change that likely caused bug 471682, at least as fixed by me, was in 2002. It's possible something broke it later, but this is not a recent problem.
(In reply to comment #11) > The original change that likely caused bug 471682, at least as fixed by me, was > in 2002. It's possible something broke it later, but this is not a recent > problem. I see. I guess; (1) Problem in "open mail folder other than via UI" existed nearly since initial. But it didn't produce severe problem long time. (2) mail.db_timestamp_leeway was introduced. (to avoid frequent .msf recreation in multi-boot env or network file env) (3) To resolve problem by (2), file size check(of mail folder file) was added. (4) Bug 392704 changed rebuild index code(to not to loose tag/junk status etc.) (5) Many problems have been exposed by change of Bug 471307...