User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

Steps to reproduce:

Forward a message with attachments with auto-draft saving enabled for every two minutes.

Actual results:

After waiting a few minutes (<5 minutes), thunderbird access to the attachments in the original message is lost. An error message titled "Save Draft Error" shows

"Unable to save your message as a draft.There was an error attaching TIC344541836.13_20210901_GdP-0.4m_zs_measurements.apertures. Please check that you have access to the file."

The original email with attachment is still in the inbox and has not been changed. This is not a one-time event. It happens ~70% of the time with my installation. If one then attempts to send the message, the following error is given "Send Message Error" with content

"Sending of the message failed.There was an error attaching TIC344541836.13_20210901_GdP-0.4m_zs_measurements.apertures. Please check that you have access to the file."

The only way to correct the problem is to reattach the files by dragging them from the original email.

Expected results:

The file access to the original email should not be lost.

I cannot reproduce this with TB91.1.1 in combination with the auto-save function.
Possibly it has nothing to do with it at all. A similar issue has just been fixed in Bug 1727830.
Please test it again once TB91.1.2 is released.

Unfortunately, the problem continues to happen in Thunderbird 91.1.2 (64-bit) Windows 10.

As FYI, this problem does not occur with the same user profile when running TB 60.9.1 (I'm not sure about releases in-between).

Just wanted to confirm this bug.
I have seen this running TB 91.2.1 on both Linux and Windows.

I have also noticed the same behavior (only on windows for now) after having attached some files to a newly created email.

I could not notice any time-related behavior like the OP reported. I'm not sure now, but I believe that discarding the composed mail and restarting TB fixes things. However that's counterproductive, because one has to copy the content and reattach all files (because the composed mail cannot even be saved as a draft).

Any improvement using 91.3?

(In reply to Arthur K. [He/Him] from comment #5)

Any improvement using 91.3?

Installed 91.3 on Windows yesterday. So far so good, but the bug wouldn't happen all of the time. I'll keep an eye on it and report.
I am waiting on TB on Linux (Ubuntu 21.10) to update to 91.3. Should hopefully be any day now.

(In reply to Frank Mayer from comment #6)

(In reply to Arthur K. [He/Him] from comment #5)

Any improvement using 91.3?

Installed 91.3 on Windows yesterday. So far so good, but the bug wouldn't happen all of the time. I'll keep an eye on it and report.
I am waiting on TB on Linux (Ubuntu 21.10) to update to 91.3. Should hopefully be any day now.

Thanks for the feedback. In the instances where you're likely to experience the issue through your own regular use, do a CTRL-SHIFT-J to open Error Console before you intend to send an email. It might also yield some clues.

Thanks for the feedback. In the instances where you're likely to experience the issue through your own regular use, do a CTRL-SHIFT-J to open Error Console before you intend to send an email. It might also yield some clues.
OK, thanks for the tip - will do.

I have the same issue and the Error Console give me this :

mailnews.send: Failed to fetch attachment; name=Superbe grandiose.mp4, url=file:///C:/Users/Andre/AppData/Local/Temp/nsmail.mp4, error=asyncFetch failed with status=2152857618 MimePart.jsm:159:29

mailnews.send:
Exception { name: "", message: "Failed to fetch attachment", result: 2153066778, filename: "resource:///modules/MimePart.jsm", lineNumber: 162, columnNumber: 0, data: XPCWrappedNative_NoHelper, stack: "getEncodedBodyString@resource:///modules/MimePart.jsm:162:26\n", location: XPCWrappedNative_NoHelper }
​
columnNumber: 0
​
data: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface() }
​
filename: "resource:///modules/MimePart.jsm"
​
lineNumber: 162
​
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
​
message: "Failed to fetch attachment"
​
name: ""
​
result: 2153066778
​
stack: "getEncodedBodyString@resource:///modules/MimePart.jsm:162:26\n"
​
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
MessageSend.jsm:122:27

2152857618 is NS_ERROR_FILE_NOT_FOUND (https://james-ross.co.uk/mozilla/misc/nserror?0x80520012)
Either you or Thunderbird must have removed the file.

I think this is a duplicate of bug 1735601, hopefully will be included in the next 91 release. Please see if you can reproduce on a beta or daily build.