356919 - After sending an e-mail with an attachment received by Thunderbird using SimpleMAPI, the temporary moz_mapi attachment file doesn't get automatically deleted, if the file has read-only attribute or is locked at the time of sending

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[stoilis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla Thunderbird 1.5.0.7 Build 20060909

The problem described is only reproducible under very specific and obscure conditions so I will try first to describe the background, hoping not to bore you too much. Combined with bug 356808 that I submitted yesterday, this makes Thunderbird include wrong attachment on e-mails several times a day. Bad.



Reproducible: Always

Steps to Reproduce:
A company I support has a software called FileNET (http://www.filenet.com/) for Document Management. The windows client version integrates with Windows's Explorer, so that one can see and manage documents imported into a remote FileNET's database, like handling local files.
This is a cool feature that allows transparently handling remote files like local ones. For example, one can right click any document inside Filenet's space in a Windows Explorer window and get the classic right-click explorer menu to further commit an action on a file, like Copy, Paste and more importantly, Sent to->Mail Recipient.

When using Thunderbird as a client and doing a "Sent to->Mail Recipient" on a file throught Filenet's space in Windows Explorer, the mail is sent normally. However, the temporary file that is created in moz_mapi temporary attachment directory is never removed!

I've tried it numerous times. When attaching a file from a non-standard path using SimpleMAPI, the temporary file in moz_mapi never gets deletes. When attaching it from a standard path, it get deletes afterwards normally.

This bug alone is so osbscure that it isn't much of a bug actually. However, combined with bug 356808, it causes big troubles, like helping add wrong attachment in sent e-mails.

Comment 1

[Mike Cowperthwaite]

I'll confirm this because I've discovered files left in the mozmapi temp directory, but I don't know how to reproduce it.

Comment 2

[Hungerburg]

I know a way to easily reproduce:

- in Windows explorer with e.g. a pdf file
- do a "Send To -> E-Mail"
- thunderbird composer comes up
- open above file (the copy) with acrobat, keep it open
- perform or cancel thunderbird compose
- copy will be left in "moz_mapi" temp folder
- as long as its open in acrobat, even explorer cannot delete the file!
- the next time you compose a message and attach a file by the same name, even if the original file changed, and the copy is no longer locked, thunderbird will not again copy the file, but use the stale one instead!

This is VERY BAD behaviour - imagine a billing application that calls TB - you will send confidential business information to a third party! It was MUCH BETTER to send no file at all, than the wrong file!

I would very much like to escalate the bug. How to tag this "security" - thats what it is about: TB compromises user security!

This is only one way, there are others I still try to find out - one other way to trigger an error quite like that:

- do a "SendTo -> E-Mail" twice with the same file
- two files will be in "moz_mapi" directory
- one has "-1" appended to the filename
- both composers reference the first file!
- after closing thundebird, the second file becomes stale

Peter

PS: the linux version does not copy attached files, it always keeps a reference to the original while composing.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Reproducible: Always
> Steps to Reproduce:
>(snip)
> I've tried it numerous times. When attaching a file from a non-standard path
> using SimpleMAPI, the temporary file in moz_mapi never gets deletes. When
> attaching it from a standard path, it get deletes afterwards normally.

When sent file has Read-Only attribute, "remained file in moz_mapi after close of Compose Window" can easily be observed.
 (1) Set Read-Only attribute of a pdf file
 (2) Send the pdf file by Adobe Reader 8 via MAPI
 (3) "Send Later" at mail compose window
     => Copy of the pdf file still remain in moz_mapi
        The file has "R" attribute
        "DEL" command at Command Prompt is rejected due to "R" attribute
Is this the case?

Comment 4

[Douglas]

Defect still present in 2.0.0.19 on WinXP.

Sending any read-only file via MAPI causes the temporary file to remain in the Local Settings\Temp\moz_mapi directory. Subsequent sending of the same file (name) by MAPI will send the old version.

Thunderbird (is this Thunderbird's fault?) is failing to delete the read-only file from moz_mapi after sending it.

In our case, a user was sending a source-code file that had been locked by Subversion, and was therefore read-only on his local HDD. He was most surprised to find that he'd sent a version that was many months old.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> Defect still present (snip) on WinXP.
> (snip) He was most surprised to find that he'd sent a version that was many months old.

FYI.
Putting shortcut of a BAT in "Start Up" folder will reduce frequency of such surprising on MS Win.
> DEL-TMP.BAT
>   DEL %temp%\*.* /S /F /Q

Comment 6

[Heinz Moeller]

(In reply to comment #4)
> Defect still present in 2.0.0.19 on WinXP.
> 
The problem still exists in 3.0.1 (Windows).

In my case, sending several invoices (for example invoice.pdf, invoice-1.pdf, invoice-2.pdf) will always send the first file to all customers. embarrassing!

different to prior reports, i cannot find read-only files in ...temp\moz_mapi. perhaps this has been changed.

a solution would be really appreciated.

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> (In reply to comment #4)
> > Defect still present in 2.0.0.19 on WinXP.
> > 
> The problem still exists in 3.0.1 (Windows).
> 
> In my case, sending several invoices (for example invoice.pdf, invoice-1.pdf,
> invoice-2.pdf) will always send the first file to all customers. embarrassing!
> 
> different to prior reports, i cannot find read-only files in ...temp\moz_mapi.
> perhaps this has been changed.
> 
> a solution would be really appreciated.

Your issue is actually bug 356808 which has been fixed in Thunderbird 3.0.2 and is expected to be released on Thursday.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Morphing this bug slightly - limit to "not deleted if read only attribute".
If other case than "read only attribute" case will be found, open separate bug, please.