お世話になります。

ThunderbirdからIMAP接続でExchange Online(Office365)に接続し、利用しています。
フォルダを作成し使用していた所、急に特定のフォルダがThunderbird上から表示されなくなる現象が発生しました。

以下の【確認内容】を行いましたが、改善されず、対象のフォルダ内のメールを確認することができません。
Outlook on the web(旧Outlook Web App)上ではフォルダが表示されているため、Thunderbird側に原因があると考えています。
複数のユーザーにて発生しており、対応方法がフォルダ名を短縮する程度しかなく根本解決が出来てません。
Exchange OnlineとのIMAP接続について制限や仕様、不具合等の情報がありましたら、情報提供頂けないでしょうか。

【環境】
OS :Windows7 Pro SP1 or Windows10 Pro
Thunderbird :38.8.0 or 45.3.0
メールサーバ:Exchange Online(Office365)

【手順】
1.Thunderbird上にアカウント追加(Exchange Online)
2.受信トレイ配下に任意のフォルダ階層を作成
3.購読にチェックが入っていることを確認し、OK

【確認内容】
(1)セーフモードにて起動
改善せず

(2)フォルダの再作成
改善せず

【調査内容】
(1)フォルダ名の文字数制限
Thunderbirdでは、フォルダの文字列長は250文字まで作成可能

(2)フォルダが非表示になる条件
各フォルダにて、右クリック-[プロパティ]を選択し、[フォルダのプロパティ]を表示し、
[場所]の文字数が582文字までのフォルダは表示される。
583文字以上になると、フォルダが表示されなくなる
※添付の画像参照

(3)Outlook on the webでの動作
Thunderbirdで作成したフォルダは表示されており、メールの参照等操作可能

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0

「急に」は、ある環境のあるThunderbirdにおいて、長いフォルダー名でも全然問題なく使えていなのに、ある日突然、何も変えてはいないのに、特定のフォルダがThunderbird上から表示されなくなった、ということでしょうか？


これだけきちんと調べがついていると、話が早い。

［MSのMAX_PATH関連の話] によると、Win10ではAPIでの長さ制限をなくしたようですね・

Win10よりも前でも、MAX_PATH関連の設定を変えて、260よりも制限を長くできますから、Win 10に限った話ではないですね。

MAX_PATH(Linuxだとpath_max)の周辺で、いくつかのバグが報告されています。
　［ Bug 176943 ］, ［ Bug 249807 ］ , ［ Bug 752085 ］ , ［ Bug 1093860 ］
Bug 752085は、MAX_PATHを大きくしているにもかかわらず起こる問題かもしれない、と思ったが、明らかにMAX_PATH=260による現象のBug 249807 のDUPにされてしまった。

Bug 1093860 が、LinuxでPATH_MAX=4096 なのに、500文字超のところあたりでカットされてしまう、という現象の報告です。
Win10で起こっている現象は、このバグと似たような問題に思われます。
[場所]の文字数が582文字！＝file pathの長さが582、ですが、どこかの場所で582の近辺の何らかの長さ制限があってカットされているように思えます。
Thunderbirdの内部で、という可能性が高そうです。

以前テストした時には、Thunderbirdでのローカルフォルダー名の長さ制限は128だったから、"C:\" + フォルダー名 + ".msf" が256文字以内ならばＯＫになるようになったのかな？


それくらいしか、逃げ道は思いつきません。

なお、IMAPの場合、サーバーから送られてくるMbox名は、Modified UTF-7で(自分でググってください)、そのModified UTF-7の文字列をローカルのファイルのファイル名に使います。
Modified UTF-7ですから、日本語のMbox名だと、ファイル名の文字数が4/3くらいに増えます。

他の逃げ手です。

メールフォルダー用のファイルへのフルパスが長くなる原因の一つは、プロファイルディレクトリーのパスが長くなることです。
普通は、<非常に長いプロファイルディレクトリーのパス>/Imap/<server名>/<メールフォルダー用のファイル> になり、
<非常に長いプロファイルディレクトリーのパス>　が下手をすると、256文字の半分くらいを占有してしまうこともあります。

（Ａ）　<非常に長いプロファイルディレクトリーのパス>　⇒　C:/TbProf/<random>.default に移動する。
　(手動でのprofiles.ini の編集、　新規プロファイルの作成時にC:/TbProf/<random>.defaultを選択、などが要る)
（B）　アカウントのメールディレクトリーだけを、C:/TbMail/Imap/<server名>に移す。
　(ディレクトリーを手動で移動した後、サーバー設定のメッセージの保存先を変える必要がある)

「プロファイルディレクトリーごとコピー・移動」がいつでも効くようにしておくためには、(A)の方がいいでしょう。

いづれにせよ、panacea.dat(万能薬.dat、FolderCacheのデータが入る)に保存されている各Ｍｂｏｘ用のファイルのパスが絶対パスである為に、(A)/(B)を行った後の最初のIMAPサーバーへのアクセスでは、サーバーとの同期状態が失われてゼロからのスタートとなって、関係するＩＭＡＰアカウントの全メールフォルダーの全メールをサーバーから再度ダウンｆロードすることになりますから、巨大なメールフォルダーを愛用している環境では、注意が必要です。

WADAさん

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

Linux版ではそのようなバグがあったんですね。
Windowsでも似たような不具合であれば修正に持っていければと考えています。

また、プロファイルディレクトリーのパスを短くするアイデアもありがとうございます。
私だけであれば問題無いのですが、多数のユーザーに影響があるので行うとしても限定的になりそうです。

この現象は他の方は発生していないんでしょうか…。
また、この現象がThunderbirdの不具合の場合はBugzillaに挙げるのが最善なのでしょうか。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0

Bug 1093860 は、Filenameの長さが256文字に制限される、という部分についてであって、「260文字 ＜ 500文字とちょっとあたり ＜＜ path_max」 でパスが切られてしまう、というのは、バグ番号をもう一度見つけられなかった別のバグでした。
Loinux/path_maxだったので、そっちだと即断してしまいました。


MAX_PATH=260の制限も、昔は、終端のヌルを含んで260バイトだったのが、Unicodeになってから、終端のヌルを含んでUTF-16の260文字、というような変化がありますし、
内部的には、常にUTF-16だけで処理しているわけではなく、UTF-8で行っている場合もあります。
そして、いろいろな場所で、260バイトだったり、260Unicode文字だったり、URF-16は2バイト文字だから260X2バイトだったりと、長さ制限を踏まえて、何らかのワークエリアやバッファーのサイズの制限をしています。
無限に長い文字列を常にサポートするなんてできないですからね。
結局、どこかで260Unicode文字以上を処理できるようにしても、おっつけ、どこかの制限の一番小さなところで切り捨てられるでしょう。
一つボトルネックをつぶせば次のボトルネックがでてくる、で、もぐら叩きみたいなもの(^^)

今回の現象が、Thunderbirdの中の問題なのかＯＳ側の問題なのかはわかりませんが、多くの場合、Thunderbird側の問題でしょうね。
bugzilla.mozilla.orgにバグを開いて、きちんとした問題判別のためのデータを提供して、デベロッパーによる解析を待つ、というのが、正当な手段だと思います。

今までは260文字を超えるとフォルダーが消える、だったのが、
２倍以上の580文字くらいまではフォルダーが消えることなく大丈夫になったんだから、大幅に改善されているわけで、
緊急を要する問題でSeverity=1/Priority=1でこのバグが直るまでは出荷停止、ってなことにはならないと思いますけど。

興味があったので、ちょこっと追試してみました。

以下の、100Unicode文字のメールフォルダーを、Win10上のThunderbirdのダミーのPOP3アカウントに作ってみました。


三階層目まではフォルダーを作ることができ、メールのコピーも可能。
（円記号＝バックスラッシュはスラッシュに変えてあります）
C:/Users/Wada/AppData/Roaming/Thunderbird/Profiles/2vf4qc8s.default/Mail/a.a.a/Ａ１２３４５６７８９Ｂ１２３４５６７８９Ｃ１２３４５６７８９Ｄ１２３４５６７８９Ｅ１２３４５６f143dd46.sbd/Ａ１２３４５６７８９Ｂ１２３４５６７８９Ｃ１２３４５６７８９Ｄ１２３４５６７８９Ｅ１２３４５６f143dd46.sbd/Ａ１２３４５６７８９Ｂ１２３４５６７８９Ｃ１２３４５６７８９Ｄ１２３４５６７８９Ｅ１２３４５６f143dd46.msf

最下層の.msfファイルのパスの長さは、399バイトです。
「～.msfのファイル名」も「～.sbdのディレクトリー名」も、長さは 106バイト。
ローカルフォルダの場合、フォルダー名が128バイトを超していてファイル名がそれ以上になってしまう場合に、
後ろの部分をハッシュして短いファイル名にして、フォルダー名は.msfの中に書く、ということが、今も行われていました。

しかし、以下のディレクトリーの下にそれ以下の階層のフォルダーを作ることは、たとえ半角の「A」であっても、何もしてくれませんでした。
サブフォルダーの作成をリクエストしても、エラーが起こると何の応答も返さずに単に無視、という既知の問題が起こります。
（円記号＝バックスラッシュはスラッシュに変えてあります）
C:/Users/Wada/AppData/Roaming/Thunderbird/Profiles/2vf4qc8s.default/Mail/a.a.a/Ａ１２３４５６７８９Ｂ１２３４５６７８９Ｃ１２３４５６７８９Ｄ１２３４５６７８９Ｅ１２３４５６f143dd46.sbd/Ａ１２３４５６７８９Ｂ１２３４５６７８９Ｃ１２３４５６７８９Ｄ１２３４５６７８９Ｅ１２３４５６f143dd46.sbd/Ａ１２３４５６７８９Ｂ１２３４５６７８９Ｃ１２３４５６７８９Ｄ１２３４５６７８９Ｅ１２３４５６f143dd46.sbd

最下層のディレクトリーのパスの長さは、399バイトです。
.sbdディレクトリーのパスの長さが259以下なら、その下に、拡張子無しファイル/～.msfファイル/～.sbdディレクトリーを作りに行くが、
.sbdディレクトリーのパスの長さが259を超えているとギブアップ、なのかな？

[訂正]
最下層のディレクトリーのパスの長さは、258 Unicode文字、でした。
全角を半角にしてみて、気付いた。
その下のファイルは、/Z (円記号はスラッシュで表示) と、最低限2文字になるので、259文字を超してしまう。
MAX_PATH=260だった頃のままにThunderbirdが自主規制している、ってな感じなのかも。
でも、そうしないと、Win10環境とそれ以外でのメールフォルダーファイルの互換性が失われる。
[訂正おわり]

IMAPとローカルフォルダーでは、ファイル名の使い方が異なるので、現象は異なりますが、
Win10になって、APIにおいてはMAX_PATH=260の制限はなくなったが、色々な所のいろいろな長さ制限がまだある訳で、
無限に長いファイルパスになるようなメールフォルダー・メールフォルダーの階層が使えるようになったわけではない、
ということは、言えると思います。

WADA さん

お忙しい中検証まで行って頂きありがとうございます。

258 Unicode文字を超えると発生するとのことですので、こちらで検証した結果と若干異なりますが、
エラーも発生せずフォルダが作成できなくなったとのことですので、現象としては非常に似ていますね。

互換性を考えると、長いフォルダパスを作ることが出来ないとのこと承知しました。

実はExchange Onlineでのメール利用は最近からであり、以前はオンプレでメールサーバーを利用していました。
その頃はもう少し長い文字列だと発生していたようなのですが、Exchange Onlineに変わってエンコードの方式が変わって
文字数が長くなりやすくなってしまったのかもしれませんね。
以前のメールサーバーはまだ生きているので、そちらと同条件で検証し、パスが異なるか確認してみたいと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0