偶然的通行人 さんが書きました:
受信メッセージの添付ファイルを、直にメッセージ作成ウィンドウに添付したとき、アタッチメントボックスに表示されたファイル名のツールチップを確認すると、受信メッセージのパス情報が表示されるはずです。
例えば、アカウント X の [受信トレイ] にあるメッセージに添付されていた bbb.pdf を新規メッセージに直接添付した場合、パスは次のように表示されるはずです。
mailbox:///C:/Users/<UserName>/AppData/Roaming/Thunderbird/Profiles/xxxxxxxx.default/Mail/<AccountX>/Inbox?number=nnnnnn&part=1.2&filename=bbb.pdf
(0) この時点では、作成しているメールの添付ファイルは、
FileName=bbb.pdf
データのURL=mailbox:///C:/Users/.../Inbox?number=nnnnnn&part=1.2&... (Inboxの中のあるメールのあるパート
(1) 添付をリネームすると、
FileName=bbb-Renamed.pdf
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&part=1.2&... (Inboxの中のあるメールのあるパートのまま)
(2) このメールをドラフトに保存する、あるいは、このメールがドラフトに保存されても、
FileName=bbb-Renamed.pdf
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&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&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が使われていたかとか(ツールチップの文字列)、
誤って添付されていたデータがどのメールの(受信順カラムの値)のどのパートのものなのか、
などについての情報が、問題を報告された方によって提示されていないので、
実際にどのような問題が起こったのかについては、何も言えません。
しかし、上記のようなことがあれば、おっしゃるような現象が起こり得る、ということは言えます。
[quote="偶然的通行人"]受信メッセージの添付ファイルを、直にメッセージ作成ウィンドウに添付したとき、アタッチメントボックスに表示されたファイル名のツールチップを確認すると、受信メッセージのパス情報が表示されるはずです。
例えば、アカウント X の [受信トレイ] にあるメッセージに添付されていた bbb.pdf を新規メッセージに直接添付した場合、パスは次のように表示されるはずです。
mailbox:///C:/Users/<UserName>/AppData/Roaming/Thunderbird/Profiles/xxxxxxxx.default/Mail/<AccountX>/Inbox?number=nnnnnn&part=1.2&filename=bbb.pdf[/quote]
(0) この時点では、作成しているメールの添付ファイルは、
FileName=bbb.pdf
データのURL=mailbox:///C:/Users/.../Inbox?number=nnnnnn&part=1.2&... (Inboxの中のあるメールのあるパート
(1) 添付をリネームすると、
FileName=bbb-Renamed.pdf
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&part=1.2&... (Inboxの中のあるメールのあるパートのまま)
(2) このメールをドラフトに保存する、あるいは、このメールがドラフトに保存されても、
FileName=bbb-Renamed.pdf
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&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>のデータで起こった場合の問題が、[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1201782]Bug 1201782[/url]です。
他の既存のメールの添付ファイルをドラッグ&ドロップしてメールに添付した場合には、
データのURL=mailbox:///C:/.../Inbox?number=nnnnnn&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が使われていたかとか(ツールチップの文字列)、
誤って添付されていたデータがどのメールの(受信順カラムの値)のどのパートのものなのか、
などについての情報が、問題を報告された方によって提示されていないので、
実際にどのような問題が起こったのかについては、何も言えません。
しかし、上記のようなことがあれば、おっしゃるような現象が起こり得る、ということは言えます。