731907 - Canceling sending e-mail removes attached file from hard drive.

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[AndrzejL]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120229 Firefox/13.0a1
Build ID: 20120229031108

Steps to reproduce:

Hi all.

I am using PCLinuxOS 2012.02 fully upgraded. I am using Thunderbird Daily 13.0 installed it this way:

http://andrzejl.no-ip.org:10101/wordpress/2012/02/09/testing-mozilla-thunderbird-aurora-earlybird-12-safely-on-pclinuxos-2011-x/

Don't mind that it says Aurora I am using Comm Central.

I have attached a .png (does not matter what file is used) file and I have added a recipient of the message. I clicked Send button but before it was sent I have recalled that I was suppose to send this file to two recipients instead of one so I have cancelled the sending process and added another recipient to the BCC field.


Actual results:

When trying to send e-mail I received this error:

"Sending of message failed.
Unable to open the temporary file /path/to/the/file.png. Check your 'Temporary Directory' setting."

When investigating the error I have noticed one thing. The file .png that I have attached to the message was gone from the hard drive. Luckily I had backup of the file... So I copied backed up file to the folder again and repeated the steps (sending, canceling, sending again) and it happened yet again. I tried different files with different extensions. Makes no difference. If You cancel sending the message and the message contains attachment the attached file will get deleted from hard drive... Really nasty bug (a lot of people will learn the hard way to backup their files :D).


Expected results:

The file should remain untouched on the hard drive after sending message was canceled.

Regards.

Andrzej

Comment 1

[Magnus Melin [:mkmelin]]

Whow! I just tried this on latest trunk and it's reproducible. tb 10 works as it should.

Comment 2

[Magnus Melin [:mkmelin]]

I bet this is from bug 235432. Couldn't reproduce using a trunk build from 2012-02-21.

Comment 3

[:aceman]

The patch in bug 235432:
http://hg.mozilla.org/comm-central/rev/1b2d1c269c89

Does mTmpFile point to the original file if it is on the local filesystem and no copy was needed?
Only for the composed message is a temporary file created?

Have you tried reverting that patch?

Comment 4

[Manfred]

Same problem here with Windows XP - if there are more than 9999 tmp-files left I get the message "Sending of message failed. Unable to open the temporary file..."
If I delete all files in Temp folder it works great!
Would be great if thunderbird could remove all his temp-files from time to time...

Comment 5

[:aceman]

I don't think this comment belongs into this bug.
Maybe you wanted bug 389132 or bug 235432?

Comment 6

[Joe Sabash [:JoeS1]]

Not just Linux.
Confirmed on WinXp, by hitting Escape with a send in progress.

Comment 7

[Magnus Melin [:mkmelin]]

Another way to cancel easily is using an smtp which doesn't have password saved.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

Attachment: Fix

AndrzejL, thank you for your reporting.

This bug is all my bad.
I had not noticed the mTmpFile is modified in nsMsgComposeAndSend class.

This patch is a quick fix for the problem.

We should also fix nsMsgComposeAndSend class not to access to the mTmpFile directly and mTmpFile is not good name for the purpose which is done in nsMsgComposeAndSend (mTmpFile is the original file in this bug case).
 
Anyway, I am sorry for this bug, and thank you for your reporting.

Comment 9

[AndrzejL]

Hiroyuki Ikezoe I am delighted to be able to test (and discover bugs in) Firefox and Thunderbird as this is the only way that I am able to help You guys improve my favorite software. Don't feel bad about it and don't beat yourself up. I cannot code myself so what You do guys is kinda like magic to me ;). All I can do is test / report bugs and help with some simple queries on the irc channels. That's my share of helping.

The patch will be added to one of the next updates in the daily update schedule or would I have to patch it myself by hand? I think it will be updated automagically but just asking to make sure.

Thanks for fixing this. Keep up to really good work You guys!

Andrzej

P.S. Now that I have Your attention... I have an idea... I think it's good... Please read this if You can (and if You want let me know what You think) http://andrzejl.no-ip.org:10101/wordpress/2012/02/09/i-have-an-idea-for-a-project-for-mozilla-developers/ I am contactable via mail and on mozilla irc network :). I would be delighted to see this project going...

Comment 10

[David :Bienvenu]

Comment on attachment 602104 [details] [diff] [review]
Fix

Hiro, sorry I didn't catch this in review. I spent the afternoon tracking down a similar issue in some new code I'm writing; that compose code is scary! I'll land this right away.

Comment 11

[David :Bienvenu]

fixed on trunk, which is the only place the regression is, I believe - http://hg.mozilla.org/comm-central/rev/9fb387de35bd

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I've opened a new bug for a test of this bug. bug 732334

Comment 13

[:aceman]

(In reply to AndrzejL from comment #9)
I cannot code myself so what You do guys is kinda like magic to
> me ;). All I can do is test / report bugs and help with some simple queries
> on the irc channels. That's my share of helping.
That is very good, thank you!

> The patch will be added to one of the next updates in the daily update
> schedule or would I have to patch it myself by hand? I think it will be
> updated automagically but just asking to make sure.
Now that it was checked into trunk, you should see it automatically in tomorrow's build. Then please test it and if it works, change the status of this bug to VERIFIED FIXED.
Thanks.

Comment 14

[AndrzejL]

Yup. It's fixed :hiro :).

Thanks for the tip :aceman.

Regards.

Andrzej

Comment 15

[:aceman]

Cool, it took about 20 hours to fix this problem :)
Congrats, :hiro!