Thunderbirdでメール作成時の添付ファイル名変更で不具合と思われるので報告します。

Ver38.4.0


メールにて添付ファイルを受信します。
↓
新しいメールを作成し、受信した添付ファイルをThunderbird上からそのまま新しいメールに添付します。
↓
添付したファイルのファイル名を変更します。
↓
ファイル名が特定の場合、過去送信したファイルに置き換わります。
(私の場合、【記入済】や、【作成済】といったものを入れると、過去の送信データへとファイルが置き換わってしまいました)

ちなみに、ファイル名を変更する直前(新しいメールにファイルを添付したところ)まではファイルがもとのままであることは確認済です。

現状同様の操作で3回送信ミスを繰り返しており、現在ファイル名を変更する際は全てローカルに別途保存してから行うように変えております。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

いくつか補足させて頂きます。

・ファイル名の変更について
thunderbirdの新しいメール作成上で、添付ファイルを右クリックし、ファイル名の変更としています。
受信側でファイル名を変えたりはしていません。


・OS環境　
　Windows7 64bit


・入れ替わるファイルについて
特定の過去送信したデータに入れ替わります。
私の場合は2014年6月に送信したPDFデータへと入れ替わりが確認できました。
ファイル名については文頭に【作成済】といっ言葉が入っていた事のみ共通点で、その他ファイル名が同じといったことはございません。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

Windows8.1+Thunderbird38.4.0でやってみましたが再現しませんでした。

というのは、Thunderbirdのアタッチメントバーからメール作成画面にドラッグした、ということでよいですか？(添付ファイルの場所がアタッチメントバー)

もう少し具体的に操作手順

1. 過去に受信したメールの添付ファイルについて、アタッチメントバーからメール作成画面にドラッグする
2. メール作成画面にて、右クリックから「名前を変更」で添付ファイルの名前を変更(元のファイル名の冒頭に【記入済】と追加）
3. 添付ファイルの中身を確認

としていますが特に内容が変更された形跡はありません。

この、2014年6月のPDFデータ名は、今回変更をかけた後のファイル名と同じですか、異なりますか。

38.4.0に上げてから起きたとかであれば、アドオンの干渉も考えられるため、セーフモード等での定石的な確認を勧めます。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

　
＊質問した後やアドバイスをもらった後は、放置せずに、結果や経緯を必ず書くように
　しましょう。
＊ここは、相互ユーザサポートを通じて、各種情報・事例を、ユーザ同士でシェアする
　場でもあります。　
　
　
当方でも meeyar さんと同様で再現しませんでした。
[環境：OS:Windows 7 Professional SP1 + Thunderbird 38.4.0 日本語版]

[操作手順]
１．受信メッセージの添付ファイルをアタッチメントバーから新規メッセージ作成画面にドラッグする
２．メッセージ作成画面で、添付したファイルを選択して、右クリックから「名前を変更」で添付ファ
　　イルの名前を変更（【変更済】をファイル名の冒頭に追加）する

[結果確認]
１．添付ファイル名を変更した時点で添付ファイルを開いて内容を確認するが、正常のままで添付ファ
　　イルが別のものと入れ替わってる状態は確認できず
２．そのまま自分宛に送受信のテストをおこなうが、送信済みメッセージも受信メッセージも添付ファ
　　イルの内容は正常なままで、添付ファイルが別のものと入れ替わってる状態は確認できず


【不具合かどうかの確認対処方法】
まずは Thunderbird に問題があるかどうかを確認するために、Thunderbird のセーフモード起動や新
規プロファイルでのテスト確認をしてみましょう。（これは定石です）

[参照]
Thunderbird のセーフモード | Thunderbird ヘルプ
複数のプロファイルを使用する | Thunderbird ヘルプ


上記の確認対処でも再現する場合は、寺野きん さんの環境条件を点検して、その状況を提示してくだ
さい。
例えば、添付ファイルの保管場所やその扱い方法なども含みます。
HTML 形式の受信メッセージ内に挿入リンクされているファイルなのかどうかも関係するかも知れま
せん。
また、該当 PDF ファイル以外でも再現するのかどうかも検証してみるなどです。


[参照] 類似事例の過去トピックから
MozillaZine.jp フォーラム - 添付ファイルを編集すると添付する前のファイルも変わってします。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0

meeyar様　kiki様

ご返信、ありがとうございます！

ご指摘頂きましたセーフモード・別プロファイルでの起動を試させて頂きました。

結果として
①セーフモード起動では同様の症状が起きる。

②別プロファイルでは同様の症状が起きない。


ということになりました。

また、その他のファイルも試させて頂いたのですが、
結果としてPDFのみ、「特定の文言」にファイル名を書き換えた際、「特定の過去送受信した」PDFに変更されます。
これは送信前、ファイル名を変更後、プログラムで開くを行った際に既に見ることができます。
特定の文言　と　特定の過去送受信したPDFのファイル名は別物です。

PDFも全てのPDFにおいて起きるわけではなく、名称もどういった形に変更加えれば起きるか
別のファイルで検証中です。

ただ、同一のメール、添付ファイルから同一の動作をした場合、100%同じ動作が起きるので、
別途詳しく調べていきたいと思います。

↓私が100%同一の症状が起きる場合、
①aaa[329255].pdfというファイルを受信している
②bbb.pdfというファイルを受信している
③bbb.pdfというファイルを新しいメール作成時に【記入済】aaa[329255].pdfというファイル名に変更する。
④ファイル名を変更する際、半角・全角及び入力ミスによるバックスペースなどをそれぞれ1回以上行っている。
※ローマ字全角で入力した際にエンターを押さずにバックスペースで消すなども行う
⑤aaa.pdfでもbbb.pdfでもない、全く違う過去受信したであろうPDFファイルが開く(PDFで開いた際のファイル名はbbb.pdfのまま)
※ここで開くPDFファイルがどのように受信されていたか、見覚えはあるのですが、特定ができていません。
　ただ、症状が出た場合に開かれるファイルは必ず同じものになります。

上で言うaaaやbbbはある特定のファイル名の名称です。


正直、ソフトウェアの問題なのか、PC側の別の問題なのか特定ができないので、
上のような操作はしないで行っていこうと思います。


御二方様
誠にありがとうございました！！

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

　
meeyar さんと私が示した操作手順で合っているのですよね？
手順が異なると、異なる結果になる可能性もあるので再現手順として確認しています。
ちゃんと教えてくださいね。


次に 寺野きん さんが提示された手順でおこなってみました。
結果、一部再現しましたが、一部再現しませんでした。

[再現した手順]
１．添付ファイル aaa[329255].pdf の受信メッセージと添付ファイル bbb.pdf の受信メッセージ
　　がすでにある状態
２．受信メッセージから添付ファイル bbb.pdf を新規メッセージ作成画面にドラッグする
３．添付したファイル bbb.pdf の名前を【記入済】aaa[329255].pdf に変更する。

[結果]
１．ファイル名を変更した【記入済】aaa[329255].pdf を開くと、表示上のファイル名は bbb.pdf
　　になっている（再現した）
２．ファイルの内容は、aaa.pdf でも bbb.pdf でもない、全く違う過去受信したであろう PDF ファ
　　イルではなく、変更元の bbb.pdf だった（再現しなかった）
　　　＊これは当方での当初の再現テストと同じです。


[テスト]
１．添付ファイル名を変更した新規メッセージ作成画面から、一旦下書きに保存すると再現しない
２．下書きに保存せずに、そのまま送受信しても再現しない


以上の結果から、先に紹介した過去トピックの事例と同様かと推察します。
つまり、新規メッセージ作成画面上では、添付ファイルを確定していないために起こる問題かと思わ
れます。つまり編集途中段階にあるという状態です。

そのまま送信したり、下書きとして一旦保存したり、ローカル上でファイル名を変更した後に添付す
れば、この問題は回避できるでしょう。
現状では、こういう仕様かと思われます。


[推察]
「全く違う過去受信したであろうPDFファイルが開く」のは、すでに送受信したメッセージの中に同
名の添付ファイルがあるものと推察します。
同名の添付ファイルがあるかどうか、すべての送受信メッセージを検索してみれば判明するでしょう。

別プロファイルでは再現しなかったというのは、おそらく同名の添付ファイルを含んだ送受信メッセー
ジが存在しなかったためと思われます。（当方では未検証です）

_________________
Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0

横から失礼します。

Thunderbird における添付ファイルの基本的な動作を書いておきます。
ユーザーが実際におこなっておられる操作を、これと照らし合わせることで、問題のありそうな部分を探り出す一助にしていただければと思います。

【基本動作】
電子メールにおける添付ファイルは、その名のとおりファイルの添付が基本です。
Thunderbird における操作方法は次の２通りあります。
（a）メッセージ作成ウィンドウに、システム内で認識可能な実在ファイルをドラッグ＆ドロップする
（b）編集ツールバーにある [添付] ボタンを押して開くファイル選択ダイアログから目的のファイルを指定する

ファイルの添付が指定されると、メッセージ作成ウィンドウのメッセージヘッダ―ツールバーの右端にアタッチメントボックスが現われ、そこに指定したファイルの一覧が表示されます。
このとき、表示されている添付ファイル名にマウスポインタを重ねるとツールチップが表示され、そのファイルの所在を示すパス情報が表示されます。

例えば、
C:\Users\<UserName>\Documents\bbb.pdf
を添付した場合、ツールチップには
file:///C:\Users\<UserName>\Documents\bbb.pdf
と URI 形式でパスが表示されます。

このとき、メッセージ作成ウィンドウのアタッチメントボックスに表示されたファイル名に対し、右クリックから [名前を変更] を実行しても、取り込み対象となっている元のファイル名が変更されるわけではありません。
変更されるのは、添付ファイルとして電子メールのヘッダに記される名前（＝ name や filename）です。

例えば、アタッチメントボックスで bbb.pdf と表示されているファイル名を abc.pdf に変更したとしても、取り込み対象であるファイルは bbb.pdf のまま変わりませんし、そのデータが添付ファイルとして取り込み対象になっています。
したがって、アタッチメントボックスで abc.pdf と変更したファイルを開いても、パス指定されているのは元の bbb.pdf なので、開いたときのファイル名は bbb.pdf で正解です。

次に、abc.pdf と名称を変更したメッセージを下書き保存するか、送信すると、パス指定された対象の bbb.pdf の内容がエンコードされてメールデータに取り込まれ、そのデータに対するファイル名が添付パートのヘッダに abc.pdf として記述されます。例えば次のようにです。
　name="abc.pdf"
　filename="abc.pdf"

さらにその後、下書き保存したメッセージを再編集するためにメッセージ作成ウィンドを開き、アタッチメントボックスのファイル名でツールチップを確認すると、
file:///C:\Users\<UserName>\AppData\Local\Temp\nsmail.pdf
のようになっているはずです。

これは、電子メールのフォーマットとして取り込まれた添付ファイルを、システムのテンポラリ領域にファイルとして再構成しているからです。そうすることで、ファイル自身を開いたり、内容を編集できるようになります。
この段階で添付ファイルの内容を編集すると、一時的に再構成されたファイル（ここでは nsmail.pdf）が書き換えられ、再び下書き保存するか、送信を実行すると、変更を加えられた一時ファイルがエンコードされてメールデータに取り込み直されます。

（補足）
電子メールに添付されたファイルは、電子メールの送受信が可能になるよう、エンコードされたデータとして存在しますから、それを直接編集することはできません。
ファイルとして開いたり、内容を編集する場合は、必ずファイルとして再構成（デコード）される必要があります。

以上が、実際にファイルを添付した場合の標準的な動作です。

【本件の事例と考察】
Thunderbird で受信したメッセージにある添付ファイルを、ファイルとして再構成（デコード）せず直にメッセージ作成ウィンドウにドラッグ＆ドロップした場合、添付ファイルとして認識されてアタッチメントボックスに追加されるのは、Thunderbird の独自仕様によると思われます。
厳密にいえば、添付ファイルとしての処理というよりは、受信メッセージにある（エンコード済みの）添付データがそのままコピーされる ―― というほうが適切かもしれません。
Thunderbird 以外のメールクライアントでは、エンコードされたままのデータを、新しいメッセージに添付ファイルとして直に追加することができないものは、いくつもあります。そういう意味では、受信メッセージの添付ファイルを直に送信メッセージに添付するような方法は、変則的な操作だといえるかもしれません。

受信メッセージの添付ファイルを、直にメッセージ作成ウィンドウに添付したとき、アタッチメントボックスに表示されたファイル名のツールチップを確認すると、受信メッセージのパス情報が表示されるはずです。
例えば、アカウント X の [受信トレイ] にあるメッセージに添付されていた bbb.pdf を新規メッセージに直接添付した場合、パスは次のように表示されるはずです。
mailbox:///C:/Users/<UserName>/AppData/Roaming/Thunderbird/Profiles/xxxxxxxx.default/Mail/<AccountX>/Inbox?number=nnnnnn&amp;part=1.2&amp;filename=bbb.pdf

この段階で、メッセージ作成ウィンドウから添付指定したファイル（bbb.pdf）を開くと、パス指定された添付パートを開くことになります。つまり、受信メッセージに添付されたファイルを開くのと同等の動作になります。
この bbb.pdf を開いたソフトウェアで、ファイルのパス情報を確認するとわかりますが、受信メッセージの添付を開いたときと同様にシステムのテンポラリ領域に展開された一時ファイルを開いているのがわかるはずです。
（例）C:\Users\<UserName>\AppData\Local\Temp\nsmail.pdf

この新規作成メッセージを下書き保存するか、送信を実行した場合、エンコード済みの bbb.pdf のデータ（つまり、上記 mailbox:/// 以下で指定された受信メッセージのデータ）がそのまま送信メッセージに取り込まれるはずです。

下書き保存する前に、添付したファイルの名称を変更した場合、ファイル自体を添付した場合と同様に、添付対象の元ファイル名は変更されず、添付後のファイル名（添付パートのメールヘッダの name や filename）が変わるだけ、というのが原則です。

しかし、特定のユーザー環境に存在する何らかの条件がからんでくると、添付対象のファイル自体を変更してしまうケースがあるのかもしれません。

[受信トレイ] の実体はプロファイル内の Inbox というファイルで、ここには [受信トレイ] 内に存在する全メッセージ（添付ファイル含む）のデータがまとめて保存されていますから、kiki さんがご指摘のようにファイル名変更によって指定パスに齟齬が生じるケースがあるのかもしれません。

あるいは、いったん下書き保存したあと、再編集時に添付ファイル名を変更する場合は、システムのテンポラリ領域の状態が影響してくるかもしれません。
テンポラリ領域に展開されるデータは、あくまで一時的なものであり、それを使うアプリケーションソフトやシステムが終了されると一時データも自動的に消えるのが普通です。
しかし、何かの事情でそうしたデータが消えずに残ってしまうことがあり、過去に開いた添付ファイルの一時データがテンポラリ領域に残ったままになっていた場合、その後の操作（ファイル名変更など）がトリガーになって、内容の異なるファイルを取り込んでしまうケースがあるのかもしれません。

添付ファイルの取り扱いに支障が生じた時、チェックすべき対象としてシステムのテンポラリ領域がよく挙げられるのは、上述のような理由からです。

（補足）
一般的には、それが必要なときでもシステムの再起動を避けてスリープやハイバネーションなどの機能だけで長期運用していたり、アプリケーションソフトを起動しっぱなしで長期運用していると、テンポラリ領域に不要なデータが蓄積されたり、整合性が乱れることが起こりやすくなり、その結果トラブルを自ら呼び込んでしまうことがあります。

【比較】
参考までに、当方の環境（Windows 7 / 8 上の Thunderbird 38.4.0）では、みなさんが提示されたそれぞれの手順を試しても、ご質問にあるような現象を再現させられませんでした。

新しいプロファイルでは問題が発生しなかったというご報告もありますから、現状では Thunderbird の特定バージョンに内在するバグというよりは、寺野きん さんの常用環境に何かしらの原因（またはトリガー）が潜んでいる可能性のほうが高いと考えられますね。

とりあえず以上です。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

すみません。
質問場所がここで良いのか分からないのですが、
非常に困っております。


Aさんからのメールに添付されていたPDFファイルを
Bさん（Aさん以外の誰でも）へのメールにドラッグ＆ドロップして添付した際、
異なるPDFファイルが添付されてしまう件がこれまで３度ほど発生しています。

毎回、異なるファイルが添付されるわけではありません。

ちなみに、添付されたファイルのタイトルは、添付したかったファイル名のままです。
中身だけ異なるPDFになっております。
また、異なるPDFファイルはいつも同じ内容のPDFファイルです。


対処方法としては
一度デスクトップに落としてから添付する、
送信前に内容確認する、
以外に
根本的な解決策はありますでしょうか。
よろしくお願いいたします。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0

最初の質問者である、寺野さんとは別人でよいですか？
まずはご自身の使用環境(OSの種類、Thunderbirdのバージョンなど)を書いて下さい。


昔の記事にぶら下がりは避けてください。
新規でトピックを書いて、以前の記事を引用する方が望ましいです。
また、後でも書いていますが、まずはここのトピックの内容を読んで、そこに書かれている確認や対処法などを行ってみて下さい。


PDFファイルを添付する時の操作について、

• 添付ファイルを一度ローカルに保存せず、Thunderbirdのアタッチメントバーから直接メール編集画面へドラッグ＆ドロップ
• 添付ファイルを一度ローカルに保存後に、ファイルブラウザ(Windowsならエクスプローラ、OSXならFinderのような)からメール編集画面へドラッグ＆ドロップ
• そのほか

どちらですか？
編集中のメールについて、添付ファイルの編集やファイル名変更などは行われていますか?

編集中の添付ファイルの扱いや、受信した添付ファイルを一度保存せず(ファイルとして再構成することなしに)他のメールへ添付可能な点については、既にこのトピック内で詳細な解説がありますのでご一読ください。

「根本的な解決を」ということで、さしあたってはセーフモードや新規プロファイルなどにより、個人の環境依存なのかどうかの確認をお勧めします。
※Thunderbirdは個人の設定や送受信したメールデータ等のファイルを「プロファイル」という単位で管理しています。
Thunderbird のプロファイル | Thunderbird ヘルプ
複数のプロファイルを使用する | Thunderbird ヘルプ
Thunderbird のセーフモード | Thunderbird ヘルプ

以前書いたもの
トラシュー2[アドオン依存かどうか］：セーフモードの方法
トラシュー3[まっさらな環境で確認する]:新規プロファイルの作成

これらで再現しなければ、Thunderbird側の問題というよりも、SYKさんの使用環境(使用しているプロファイル内)に問題があったと考えられます。
この場合は問題のあるアドオンを使わない
or
必要最低限のファイル(不具合を再現しないもののみを)新しいプロファイルへ移行するといったものが「根本的」な解決方法です。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

(0) この時点では、作成しているメールの添付ファイルは、
FileName=bbb.pdf
データのURL=mailbox:///C:/Users/.../Inbox?number=nnnnnn&amp;part=1.2&... (Inboxの中のあるメールのあるパート
(1) 添付をリネームすると、
FileName=bbb-Renamed.pdf
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&amp;part=1.2&... (Inboxの中のあるメールのあるパートのまま)
(2) このメールをドラフトに保存する、あるいは、このメールがドラフトに保存されても、
FileName=bbb-Renamed.pdf
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&amp;part=1.2&... (Inboxの中のあるメールのあるパートのまま)

メール送信時、あるいは、ドラフト保存時に、メッセージヘッダー上のfilenameがリクエストされたものに変わる、というだけになります。

こういった操作をしている最中に、関係するメールボックスでフォルダーのコンパクトが起こった場合に、
Thunderbird 37以前では、あるメールのnumber=xxxxで使われる値を、フォルダーファイルの中のオフセットにするので、
ポイントされているメールのnumber=xxxxの部分が変わってしまい、
ポイントしているメールが見つからないとエラーがおこる、
あるいは、オフセット=xxxxにメールがあってもpart=1.2がみつからないとエラーが起こる、
あるいは、オフセット=xxxxにメールがあってpart=1.2にあるデータがあるとそれを使ってしまう、
というような問題がありました。
この問題を解決するために、Thunderbird 37から、コンパクトでは、number=xxxxで使われる、メールのmessageKeyの値をオフセットには変えず、そのままの値を維持する、というように変えました。

しかし、Rebuild-Index(Repair Folder、フォルダーの修復、索引の再作成)が入ると、全てのメールのmessageKeyの値の割り振りをし直しますから
mailbox:///C:/.../FolderX?number=dddddでポイントされるメールが存在しなくなる、number=dddddに別のメールが来るが対応するパートのデータがない、number=dddddに別のメールが来て対応するパートのデータがある、ということは、起こり得ます。
これが、HTMLメールの<img>のデータで起こった場合の問題が、Bug 1201782です。

他の既存のメールの添付ファイルをドラッグ＆ドロップしてメールに添付した場合には、
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&amp;part=1.2&... で、Inboxの中のあるメールのあるパートのまま、ですから、
Rebuild-Index(Repair Folder、フォルダーの修復、索引の再作成)が入った時に、
number=nnnnnnでポイントされるメールが見つからない、
number=nnnnnnでポイントされるメールが見つかるが、part=1.2がない、
という場合に、number=0(オフセット=ZEROにあるメール)が使われる、ということがあるのかもしれません。
でないと、問題が起こった時に添付されたデータが、ある一つの古いメールのデータ、ということの説明がつかない。
Rebuild-Indexの後、number=nnnnnnにあるメールが来て、そのメールにpart=1.2があり、そのデータがいつも同じ、ということは、非常に考え難い。

添付の場合には、ドラフトに保存された添付ファイルのあるドラフトメールを編集すると、%Temp%ディレクトリーの下にnsmail.拡張子、nsmail-N.拡張子(N=1～9999)というファイルを作ってそれを使用しますから(file:// URLでポイントする)、
ドラフトメールの編集においては、nsmail.pdf、nsmail-N.pdf((N=1～9999)が全部存在するので、ファイルを作れず、古いデータのnsmail.pdfが使われる、という現象が起こるかもしれません。

あるメールの添付をドラッグドロップして新規に作成するメールに添付、ですから、
その「あるメール」は正常に表示されているわけで、
その「あるメール」の入っているフォルダーで、メールを作成している最中に「フォルダーの修復、索引の再構築」が発生する、ということは、非常に考えにくい。
従って、「number=nnnnnnでポイントされるメールが見つからない」は、
メールを作成中に元のメールを削除したとか、メールを作成中に元のメールを移動してしまった、
ということかもしれませんが、
添付にどんなURLが使われていたかとか(ツールチップの文字列)、
誤って添付されていたデータがどのメールの(受信順カラムの値)のどのパートのものなのか、
などについての情報が、問題を報告された方によって提示されていないので、
実際にどのような問題が起こったのかについては、何も言えません。
しかし、上記のようなことがあれば、おっしゃるような現象が起こり得る、ということは言えます。

基本的には、Bug 1201782 の現象しか見られないのだが...

(1) Inboxのオフセット=0～(AAA-1)に、複数のメールがある。
(2) Inboxのオフセット=AAAに、添付ファイル(part1.2、添付Aとよぶ)を持ったメールAがある
(3) そのすぐ後ろに、別のメール、メールXがある

この状態で新規メールを作成し、メールAの添付Aを添付すると、それは、mailbox://...?number=AAA&part=1.2でポイントされる。

(A-1) この時点で、オフセット＝AAAのメールAを削除すれば、number=AAAでポイントされるメールがないので、ドラフト保存やメール送信で、"Attaching..."となる。
(A-2) その後、コンパクト＋Repair Folder(フォルダーの修復or索引の再作成)を行えば、オフセット=AAAにメールXが来る。
(A-2-1) メールXにpart=1.2に対応するパートが無ければ、"Attaching..."となる。
(A-2-2) メールXにpart=1.2に対応するパートがあれば、メールXのpart1.2のデータが使われる。

(B) オフセット=AAAのメールを削除しなくても、オフセット=AAAよりも前にあるメールが削除された状態でコンパクト＋Repair Folder(フォルダーの修復or索引の再作成)を行えば、
(B-1) オフセット=AAAのメールが存在しない状態になれば、"Attchinng..."となる
(B-2) オフセット=AAAのメールが存在するが、そのメールにpart=1.2に対応するパートが無ければ、"Attaching..."となる。
(B-3) オフセット=AAAのメールが存在して、そのメールにpart=1.2に対応するパートがあれば、それが使われる。

この後、messageKeyにオフセットを入れることは完全に止めて、messageKeyは1から始まって1ずつ増加、に変えています。
そのために、number=Aで使われる値は、ローカルのメールフォルダー内のメッセージの順番になります。
この変更がThunderbitrd 38に入っているかどうかは不明ですが、
この変更の後のNightlyでは、削除されたメールが存在する状態で、あるいは、削除されたメールがある時にコンパクトを行った状態で、Repair Folderを行うと、
(C-1) 新たにmessageKey=Aになったメールが存在しない状態になれば、"Attachinng..."となる
(C-2) 新たにmessageKey=Aになったメールが存在するが、そのメールにpart=1.2に対応するパートが無ければ、"Attaching..."となる。
(C-3) 新たにmessageKey=Aになったメールが存在して、そのメールにpart=1.2に対応するパートがあれば、それが使われる。
ということになります、

新規作成しているメールが、number=A(messageKey=A)のメールの添付A(part 1.2)をポイントしている時に、
number=A(messageKey=A)よりも前のメールが削除された状態で、
かつ、number=A(messageKey=A)よりも後ろのメールが十分に存在する状態で、
Repair Folderを行うと、
多くの場合、number=A(messageKey=A)よりも後ろにあったメールが、number=A(messageKey=A)のメールになります。

なお、Thunderbirdのナイトリーでは、"Attacching...とはならず、エラーメッセージやダイアログがでるように改善されています。
しかし、(A-2-2) や(B-3)や(C-3)のケースでは、依然、Repair Folderの後にnumber=Aでポイントされたところに来た別のメールのデータが使われる、という現象は、避けられません。

昔の記事へぶらさがりやルールを分かっておらず投稿してしまい、申し訳ありませんでした。
ver.は常に最新に自動更新されているため、
問題が起こった際のver.は不明です。

PDFファイルを添付する時の操作については↓こちらです。

• 添付ファイルを一度ローカルに保存せず、Thunderbirdのアタッチメントバーから直接メール編集画面へドラッグ＆ドロップ

編集中のメールについて、添付ファイルの編集やファイル名変更などは、行っておりません。


meeyar様が記載いただいた内容については、勉強不足でしてすぐにはできそうにありませんが、
使用環境についてがんばって対応してみます。
ありがとうございました。

WADA様も解析いただきありがとうございます。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:49.0) Gecko/20100101 Firefox/49.0