User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

1. I start by sending email A with 2 PDFs attached.
2. In sent mail I right click email A, Edit as new, I change the recipient email address and send email B.
3. All OK
4. Then in sent mail I right click email A again, Edit as new, I change the recipient email address and send email C.
5. I get an error "Sending of the message failed. The file PDF1 could not be found" Hovering over the file in the attachment pane it is file:///tmp/nsmail-66.pdf. Checking /tmp the file is not there.
6. I close the failed compose window, repeat 2. above and it all works OK.

Ctl-U shows the attachments encoded in the sent mail message.
Every second edit as new fails with the error message. Is there some /tmp flushing going on but then reloading again. Why every second time it is OK.

Actual results:

See above

Expected results:

Emails should have been sent.

Occurs in 92.0b3 (64-bit) also and latest (as of today) 93.0a1

Forwarding the messages from sent mail does not exhibit this issue.

I can't reproduce this

What setting do you have for folder synchronisation. My mail boxes are all IMAP and I have no local synchronisation, i.e. no folders are selected for offline use.

Just thought to try this with mozregression-gui without using my current profile.
I can't replicate the problem with a single account. My profile where the bug occurs has 7 accounts.
Watching my /tmp folder during the process I definitely think it is a clean-up process deleting the attachment before the file is sent.
I could do a video, but would need to blur out all the account info to put it public. I will try to explain below what I see.

1. Single account in mozregression-gui with a clean profile. Issue not exhibited.
   a. In sent mail right click a message with 2x PDFs attached.
   b. In /tmp 2 files are created when the compose window opens, say nsmail-68.pdf and nsmail-69.pdf. The numbers allocated seem to be the first 2 available in the number sequence. I.E. it could be nsmail-65.pdf and nsmail-68.pdf.
   c. Close the compose window without any changes, there is no prompt to save. Usually the 2 files created above are removed, but sometimes they aren't and may be that is why I have 68 of them because they just keep building up when not deleted.
   d. If I send the message opened as edit as new the 2 files are attached and the message is sent and the 2 files are deleted from /tmp.

2. Using multiple accounts and my normal working profile. Issue is exhibited. With or without using mozregression.
   a. In sent mail right click a message with 2x PDFs attached.
   b. In /tmp 2 files are created when the compose window opens, say nsmail-69.pdf and nsmail-70.pdf (because the 2 from above are still hanging about after closing the app).
   As I just did the above, nsmail-66.pdf and nsmail-67.pdf were deleted, may be when I clicked into the address bar.
   c. nsmail-69.pdf and nsmail-70.pdf are deleted when the message is sent.
   d. I right-click the sent message in a. and 2 more files are created nsmail-66.pdf and nsmail-67.pdf when the compose window opens.
   e. Without editing the message, in about 10 seconds, nsmail-66.pdf and nsmail-67.pdf are deleted from /tmp.
   f. the message in the compose window fails to send with the message "Sending of the message failed. The file PDF1 could not be found", obviously because the files have been deleted.

I wonder if using the same numbering system for all those temp files, regardless of the profile in use, makes cleanup more complicated. If I am running 2 instances of TB and 2 profiles there is no way for TB to flush all the temp. files on exit because it doesn't know who they belong to. I have 177 files like nsemail-177.eml, another 184 nsmail-other extension. If the file name was prepended with the profile or TB PID may be then on exit they could all be flushed for that instance of TB.

I see the bug here. However, it is not 100% reproducible.

It's not limited to PDFs. I see it also with 2 JPGs.
I see it also when opening the composer from an template email.
However, it always seems to occur only when at least one email has been sent.

I see three scenarios:
A: "The fast one"

1. Open the composer with a prepared email
   -> Two temporary files are created: e.g.: nsmail.pdf + nsmail-1.pdf
2. Send the mail away.
3. Open the composer again with the same email
   -> Two temporary files are created with a new name: e.g.: nsmail-2.pdf + nsmail-3.pdf because the other names are still in use

=> everything is OK

B: "The slow one"

1. Open the composer with a prepared email
   -> Two temporary files are created: e.g.: nsmail.pdf + nsmail-1.pdf
2. Send the mail away
   2.1. Wait some time
   -> TB deletes the temp files
   2.2. Wait a little longer
3. Open the composer again with the same email
   -> Two temporary files are created with the old names: e.g.: nsmail.pdf + nsmail-1.pdf
   -> nothing more happens

=> everything is OK

C: "The The bugged one"

1. Open the composer with a prepared email
   -> Two temporary files are created: e.g.: nsmail.pdf + nsmail-1.pdf
2. Send the mail away
   2.1. Wait some time
   -> TB deletes the temp files
3. Open the composer again with the same email
   -> Two temporary files are created with the old names: e.g.: nsmail.pdf + nsmail-1.pdf
   3.1. Wait some time
   -> The temporary files disappear again

=> Without the files, sending is no longer possible.

So TB clears away the temporary files several times, without considering that they do not belong to the first send process at all.

TB78.13 leaves the files completely behind.
TB91.0.3 deletes the files with delay but not yet directly after sending.
TB92.0b5 is already affected by this bug.

The last patches I found mentioning nsfile* are 10 Years old.

Is this Bug 1704713?

Possibly regressed by Bug 1710220?

Turns out CloseWindow can be called multiple times, we should not removing tmp attachments more than once.

Thanks for the report and investigation. I didn't manage to reproduce, but the patch should fix it.

I am not sure of the process this goes through, but can test a nightly build when the patch is applied as I could reliably reproduce this in the nightly 11 days ago.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/d3618e3d3597
Avoid removing tmp attachments more than once. r=mkmelin

Please request 91 uplift.

Comment on attachment 9239569 [details]
Bug 1727830 - Avoid removing tmp attachments more than once. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): bug 1710323
User impact if declined: In some cases, temp files for attachments are removed when using edit as new
Testing completed (on c-c, etc.): beta
Risk to taking this patch (and alternatives if risky): low

Comment on attachment 9239569 [details]
Bug 1727830 - Avoid removing tmp attachments more than once. r=mkmelin

[Triage Comment]
Approved for esr91

Thunderbird 91.1.2:
https://hg.mozilla.org/releases/comm-esr91/rev/5dea8cea034a