Spin-off of Bug 289683 Comment #5 and Bug 376235 Comment #8. After fix of Bug 384735(folder lock after copy), phenomenon of Bug 289683 and Bug 376235 became different one. When different target folder is specified for copy and move, message filter of "copy and move" generates phantom mail at copy step. When same target folder is specified for copy and move, copy step interferes move, then move fails. Same result was obtained by "copy and move in a rule" case and "copy and move in different rules" case. As I write in Bug 376235 Comment #8, phantom mail couldn' be observed, if one more copy action is added. Rule-1 : copy to folder-A (sucsess, no phantom mail) Rule-2 : copy to folder-B (success, no phantom mail) Rule-3 : move to folder-A (interfered by Rule-1, not moved) OS : MS Win-XP SP2 Thunderbird: latest-trunk nightly. version 3.0a1pre (2007100303) Bug 384735(folder lock after copy) is already resolved. POP3, quarantining option : Off

Top-left : folder of X1 Top-right : folder of Inbox Bottom-left : folder of X2 Bottom-right : folder of X5

Mail data itself is copied to mail folder file properly (X1 in above test case). So phantom mails disappears and copied mails appears, if "Re-build Index" is executed. However, if old deleted mail(X-Mozilla-Status: 0008, 0009 etc.) exist, and if "Compact Folder" is executed, copied mails will be probably lost. It seems that phantom mail is caused by ".msf refresh of copy target folder is not done or fails". It seems that "interfere of move" is caused by "copy target folder is not closed or fails to close after copy", or "move process doesn't use already opened mail db".

I have also noticed this bug: consecutive "copy" and "move" filters (different folder destinations) that target the same message results in an empty message (newline at the end of the mbox) during the copy.

I have exactly the same problem here: Message filter of "copy and move" generates phantom mail dated 1970/01/01 at copy step. Version: Thunderbird 2.0.012 (20080213) German version. OS: Win XP For me it is a big problem. Without copy & move I can not use TB. Is there any chance to get this bug fixed?

Obviously this 2 years old bug will not be fixed in v.2.0. Does anybody know a workaround just to have that one simple mail filter rule? I only need to copy an incoming email to one folder and move that email to another folder after the copy process -- that's all. Thank you.

As I wrote in Comment #0, phantom mail was not observed when additional copy step was inserted. Following works? Rule-1 : Copy to folder-A Rule-2 : Copy to folder-B Rule-3 : Move to folder-C (When I tested, this was folder-A. ) (So move failure occurred at this step.)

(In reply to comment #6) > As I wrote in Comment #0, phantom mail was not observed when additional copy > step was inserted. Following works? > Rule-1 : Copy to folder-A > Rule-2 : Copy to folder-B > Rule-3 : Move to folder-C (When I tested, this was folder-A. ) > (So move failure occurred at this step.) No, this rule does not work. In folder-A and folder-B empty phantom mails (1970/01/01) appear in both folders. Only the moved mail in folder-C is readable. After "re-storing index" or after deleting the .msf files all mails appear o.k. OS : MS Win-XP SP2 Thunderbird: 2.0.0.12 (20080213), POP3, quarantining option: Off

Karl: I find the same as you. The 'Copy message to' action produces a phantom message in the target folder if it is followed by any action other than another 'Copy message to' action, regardless of whether the next action is in the same filter or is in another filter that matches the same message. OS: Vista x86 SP1 TB 2.0.0.12 It seems that the only workaround for this is to copy messages and then manually delete 'left over' messages from the Inbox. I hope this can be fixed for TB3.

At least the "Copy to folder" filter workes fine with 2.0.0.12 if this is the only one. With 2.0.0.14 those phantom messages appear under any circumstances and conditions. If starting from an 0 byte inbox file and 0 byte destination file and index files deleted, first copy is empty and each following copy in the dest. folder is a copy of the oldest message from Inbox. New indexing and/or compressing the desti. folder on the first copy makes it even worse. "Copy to folder" filter is not only annoying but also dangerous for those who want to make copies to a monthly archive for example and delete the originals manually at the end of month. My advice is to downgrade to 2.0.0.12 and to disable automatic updates in this case. Actually copying a message from one file to another shouldn't be a great problem and therefore it should be resolved ASAP. OS: WIN XP SP2

doesn't warrant blocking status, but assuming it's still there, should be fixed.

Tested with Tb Trunk(Gecko/2008072800 Shredder/3.0a2pre) on MS Win-XP SP3. (F-X means "Mail Folder X" in case description) Case-1 : Copy and Move in different rule Case-1-1 : Rule-1=Copy to F-A, Rule-2=Move to F-A (same folder) Case-1-2 : Rule-1=Copy to F-A, Rule-2=Move to F-B (different folder) Case-2 : Copy then Move in single rule Case-2-1 : Rule-1=Copy to F-A, then Move to F-A (same folder) Case-2-2 : Rule-1=Copy to F-A, then Move to F-B (different folder) Phantom mail problem in Case-1-1/Case-2-1 was resolved by patch for Bug 376235. When Case-1, both of COPY and MOVE were executed successfully. But when Case-2(single rule case), only COPY was executed(no filter log for MOVE). Change to FIXED(by patch for Bug 376235) I'll open separate bug for remaining issue even after patch for Bug 376235 (Case-2, single rule case, MOVE not executed).

I've opened Bug 448337 for remaining issue in Case-2-1/2.

Same bug here: consecutive "copy" and "move" filters (different folder destinations) that target the same message result in an empty message after the copy action.

This is NOT fixed, see above. Can somebody pls. reopen this bug.

(In reply to David.P from comment #16) > This is NOT fixed, see above. Can somebody pls. reopen this bug. Hi David. We don't reopen bugs after they are fixed, normally. And especially after being fixed years ago. If your problem is not described in a bug that is still open, then please file a new bug.

The bug still exists in TB version 38.7.2