User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112705 Minefield/3.0b2pre Build Identifier: version 3.0a1pre (2007112704) I have an inventory excel file that I send as an attachment every day to our customer (it has the exact same file name). I use the send email from the excel menu. When I open the file it's the version that I sent the day before. I then open my computer and delete the file from the C:\Documents and Settings\Mike.MIKES\Local Settings\Temp\moz_mapi folder then re-send the file then it's the current version. Reproducible: Always Steps to Reproduce: 1.send an excel file 2.change excel file 3.resend excel file Actual Results: Thunderbird sends the file that was previously sent Expected Results: Once the file is sent it should have deleted the temp file that it used to send the attachment.

Did you see this with 2.0 also?

I did not have to email the file when I had 2.0 so unknown.

The last 2 maybe 3 days I have not had to go in and delete the temp file

One of the updates from 12/18/07 to today has undone the fix and it's now working like it use to (in other words it's not working properly again).

"remained file in moz_mapi" can easily be observed when file has Read-Only attribute. See Bug 356919 Comment #3. And I experienced problem of "remained file in moz_mapi" several times even when file doesn't have Read-Only attribute, while test for other MAPI related problem, with Seamonkey 1.1.7, Tb 2.0.0.9, and Tb trunk (2008-01-24-03 build). So I think "not-deleted file in moz_mapi" part is DUP of Bug 356919. Problem after problem of "not-deleted file in moz_mapi" part, i.e. problem of "re-use of existent file in moz_mapi", is DUP of Bug 356808, because "re-use of existent file" can be easily be observed with any of SM 1.1.7, Tb 2.0.0.9 and Tb trunk. (1) Copy a text file to moz_mapi as x.pdf (2) Send x.pdf(correct PDF) from Adobe Reader 8 via MAPI (3) Compose window is invoked (4) "Send Later" => Attached data(Base64 encoded) is apparently data of text file at (1)

As per Wada's comment #5, all aspects of this bug seem covered by other bugs. Based on comment #0, the main problem is "re-use of existent file in moz_mapi" --> dupe of bug 356808

(In reply to comment #6) > --> dupe of bug 356808 Thomas D., really DUP? This bug is for problem of "Tb doesn't delete file in mmoz_mapi after send", which will produce bug 356808 in future. "not delete from moz_mapi after send" is independent problem from "re-use of existent file in moz_mapi", isn't it? Even when problem of "re-use" will be resolved, I think issue of "remaining garbage" due to this bug won't be resolved, unless patch for bug 356808 will resolve both problems at same time.

(In reply to comment #7) You are right, WADA, both problems need to be solved. However, as you correctly point out in your accurate comment #5, this bug covers two aspects that have already been filed as separate bugs. There shouldn't be two aspects in one bug, and unfortunately, we can't dupe against two bugs, so we'll have to go for one. Again you are right, as per the current summary we could as well dupe this against bug Bug 356919 (not deleting file in moz_mapi after send) which is the first half of the problem. However, reporter's original description in comment #0 also focusses on the second half of the problem (wrong attachment gets sent), which I think is a worse problem than tmp files not deleted on your own machine (dataloss, privacy). So I duped against bug 356808. Either way, we can't leave it unconfirmed, and we can't confirm this bug as both aspects are filed already.