447585 - (bug?) attachment added to mails are not temporary copied

Status: RESOLVED DUPLICATE of bug 378046

(Thunderbird :: Message Compose Window, defect)

Description

[Marco Trudel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: all

Adding an attachment to a mail should copy it to a temporary place. Currently, the behavior is inconsistent:
1. Adding attachments to a mail (when composing), opening and changing them edits the original file.
2. Saving a mail to edit and send it later saves all attachments. When opening them later, the copied one is edited and the original one is left untouched.
3. Also, adding an attachment to a mail (when composing) via drag and drop implies that the file is copied (especial if "CTRL" is pressed and the "+" sign is shown). This is what a standard user would expect because file copying works this way.

A user I support often did case 2. Twice already, he did case 1 and lost a lot of data because he expected that the original file will be left untouched.
The thing now is (if new attachments are saved to a temporary place), what happens with users editing their files and then discard the mail. They might expect the changes to be saved.

This problem should be handled so that both (probably very rare cases) are handled correctly.

Reproducible: Always

Steps to Reproduce:
1. Create new mail
2. Add attachment via drag and drop and press control (e.g. textfile). The mouse cursor indicates that the file is copied.
3. Open the attachment in an editor, change and save it.
Actual Results:  
The original file on the harddisk is altered.

Expected Results:  
It shouldn't be altered. It should be the original one.

Comment 1

[WADA:World Anti-bad-Duping Agency]

About same issue as Bug 378046?

FYI.
Seamonkey 1.1.x doesn't have "'Open' for attachment in compose window". So no problem like this bug won't occur with Seamonkey 1.1.x.
"Remove of 'Open' for attachment in compose window from Tb 2/Tb Trunk/Seamonkey Trunk" can be a simplest/easiest solution to avoid the "data corruption" problem.

Comment 2

[Marco Trudel]

Yes, it's the same as Bug 378046 (sorry, I searched but didn't see that one).
Closing...