User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 If you open an attachment that is in your inbox say PT.pdf in this case and leave that pdf open in the background (called #1) then do a mapi call to attach a pdf with the same name (PT.pdf) (called #2) it will attach the PT that is open (#1) to the email in place of (#2). I have done this on 2 PCs running T-bird. Once this has happened even if you close adobe (#1) will be attached to every email with a MAPI attachment until T-bird has been closed and restarted. Reproducible: Always Steps to Reproduce: 1.Open pdf email attachment from inbox and leave it open 2.Create a file with the same name and attach it using MAPI 3. Actual Results: From that point on every time you attach a file with that name the one that you left open will attach to the email until you restart. Expected Results: I would expect to be able to attach a file with the same name without them walking on each other.

Moving to MailNewsCore / Simple MAPI, please also see related MZ discussion. This somehow looks like bug 356808, but that was fixed a long time ago, thus I'm not sure if it's a recent regression or some case not covered by that fix.

rsx11 can you confirm the issue ?

Actually, I'm unable to reproduce this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7, thus same build. Opening an attachment of a message creates a temporary file in Local Settings, C:\Documents and Settings\(user)\Local Settings\Temp\blah.pdf, which remains persistent until Thunderbird is closed, so that part I can reproduce. However, using right-click > Send To > Mail Recipient uses a different Temp folder, C:\Documents and Settings\(user)\Local Settings\Temp\moz_mapi\blah.pdf, hence there is no conflict. I suspect that for some reason %TEMP% rather than %TEMP%/moz_mapi is used in your installation. I'm wondering if this is more a configuration issue within Windows XP rather than a setting in Thunderbird. On a side note, the files in moz_mapi are not deleted when closing Thunderbird.

Same problem as bug 344034? (that bug was dup'ed to bug 594243) (In reply to comment #3) > On a side note, the files in moz_mapi are not deleted when closing Thunderbird. If file has read-only attribute, bug 356919 occurs and file in moz_mapi is not deleted after successful send.

OK, I have also done it using the sendto > mail recitient and it works fine. However when done from this program that I use for my invoices it fails, every time. I will have to assume that it is something wrong with the way they did the MAPI call in their program unless you have any more ideas. Would a log help?

Where does that invoice program put its files for attachment? It looks like it's using the standard %TEMP% location, which in general isn't a problem, but any application using it has to ensure that the file name selected is unique and has to pick a different one if some other application has a file with the same name stored there already. For testing, open Windows Explorer and go to your temporary folder, which is C:\Documents and Settings\(user)\Local Settings\Temp with your Windows XP user name. Scroll all the way down, then open the invoice application and create an invoice (don't have any conflicting attachment open in Thunderbird to make sure that it works as intended). If the PDF file shows up there when you invoke the e-mail function, my suspicion should be correct. I think what's happening in this case is that Thunderbird, when opening an attachment, it will save it read-only. If you open the attachment multiple times, unique instances of the same document will be created by adding some number to the file name (e.g., blah.pdf, blah-1.pdf, blah-2.pdf, etc.). Now comes the invoice application and wants to write blah.pdf, which already is existing and write-protected. It's unable to write and does not try another file name to avoid the conflict, thus fails but yet passes blah.pdf over MAPI to Thunderbird, which instead finds the attachment it created itself there. As WADA pointed to other bugs, I don't know if either of those may be involved in creating the non-unique file name and causing the MAPI mechanism to fail, or if it's strictly an issue of the invoking application (making this bug report likely to resolve as "invalid" as there is nothing Thunderbird could do).

You can try if a workaround helps avoiding the read-only attribute to be set for the attachments TB saves in the temporary folder, thus possibly allowing the other application to overwrite it. Go into Tools > Options > Advanced, General tab and click on the "Config Editor" button. Copy-paste the preference name browser.helperApps.deleteTempFileOnExit into the search bar, nothing should show up by default. Right-click into the preference window and select New > Boolean from the context menu, browser.helperApps.deleteTempFileOnExit fills the preference name again, and set the value to "false" - restart TB. Try again with a conflicting attachment opened now, and see if it makes any difference. As side effects, Thunderbird does no longer clean up temporary files when closing, thus you may need to occasionally empty the Temp folder manually from accumulated opened attachments. Also, if you reopen the PDF attachment in Acrobat, you may surprisingly get the invoice sent via MAPI instead, given the shared use of the same file name.

Nick, can you retest in light of the previous comments and update the bug?