1147063 - No folder can be written to after a message filter with action set to delete or move message is run on a retrieved junk message.

Status: RESOLVED DUPLICATE of bug 695671

(Thunderbird :: Filters, defect)

Description

[Janusz]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20100101

Steps to reproduce:

1. Set automatic moving junk messages to the Junk folder in the account settings (Local folders).
2. Create a filter which moves (to FolderY) or removes the message. It must be set to "Filter after Junk Classification" [setting filter to copy message (without removal) does not trigger the bug]
3. Retrieve at least one message which will be classified as junk and is simultaneously  matched by the filter.



Actual results:

Messages are moved to their destination. However it becomes impossible to store a message (eg. copy or move) in(to) any folder (FolderX).


----------------

I believe this is the one of probable causes of the stuck "Copying message to sent folder" message after receiving filtered junk mail and sending a new message after.
Everything was tested with a POP/SMTP account. While sending the message was successful, it did not appear in the Sent folder.

Move filter's destination folder (FolderY) does not seem to make any difference, I have tested both a new folder and the Trash in the Local Folders.
Compacting/repairing index file of FolderX after the bug occurs does not seem to have any effect. It also does not matter if done on FolderY before starting Thuderbird.
There are no errors in the filter log; in subsequent retrieval of junk mail it indicates the message was moved successfully, but in reality it stays in Inbox.

Comment 1

[WADA:World Anti-bad-Duping Agency]

dup of Bug 695671?

Comment 2

[Janusz]

I don't think so. https://bugzilla.mozilla.org/show_bug.cgi?id=695671#c73

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to Janusz from comment #2)
> I don't think so. https://bugzilla.mozilla.org/show_bug.cgi?id=695671#c73

If so, what is difference of your problem from bug 695671, dup of that bug, bugs referred by that bug?
In any case, filter action of Delete & Stop Filter Exection won't work well as expected unless patch proposed to bug 695671 is applied.

Comment 4

[WADA:World Anti-bad-Duping Agency]

Phenomenon of "No folder can be written to after something wrong happened in message filter move" is reported to some bugs, and I saw such penomenon once when I checked Tb's behavior upon "filter move error when outdated msf condition exists in move target".
Filter action of Delete/Stop Filter Execution may be a best way to force "something bad in message filter" which consistently produce phenomenon of "No folder can be written".
If so, "No folder can be written" is merely a phenoenon after other critical bug happened, if "filter aaction of Delete/Stop Filter Execution" case.

Comment 5

[Janusz]

This gets a bit more complicated if two filters are in effect. First filter moves to the destination folder correctly, but the second one makes it stay in the Junk folder (so it does not stay in Inbox like after second retrieval). Moreover, there is an empty message created in the destination folder. Filter log shows two successful moves.
The same thing happens in the the current stable release (31.5.0), beta t37.0b1 version and and in the Earlybird 38.0a2 (downloaded today).

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Janusz from comment #5)

These are pretty simila to phenomenon observed in Bug 695671.

> The same thing happens in the the current stable release (31.5.0), beta t37.0b1 version and and in the Earlybird 38.0a2 (downloaded today).

Thanks for checking.
Target milestone of bug 695671 == Tb 37. Patch for bug 695671 didn't resolve problem?
(Status of bug 695671 != VERIFIED/FIXED, i.e. No one didn't do fix verification test.)

Comment 7

[Wayne Mery (:wsmwk)]

> Thanks for checking.
> Target milestone of bug 695671 == Tb 37. Patch for bug 695671 didn't resolve
> problem?
no - that's what reporter writes in bug 695671 comment 73

> (Status of bug 695671 != VERIFIED/FIXED, i.e. No one didn't do fix
> verification test.)

bug 695671 has an automated test test

Comment 8

[Wayne Mery (:wsmwk)]

janusz, does the problem reproduce with http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/36.0b1/ ?
If it does, then the problem should not be caused by the patch in bug 695671

Comment 9

[Janusz]

Thanks for your interest. The bug happens also with current stable 31.6.0 and 36.0b1, however it seems to be gone in the auto-updated 38beta (updated today)! I have checked it by changing versions a few times back and forth and it looks like it is consistent.
I am for marking this as resolved for 38beta, but I'm not sure if I should do it.
Thank you, developers!

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to Janusz from comment #9)
> Thanks for your interest. The bug happens also with current stable 31.6.0 and 36.0b1,
> however it seems to be gone in the auto-updated 38beta (updated today)!

Thanks for fix verification test of ptch for bug 695671.
Please change Status of that bug to .ERIFIED/FIXED.