MozillaZine.jp フォーラム https://forums.mozillazine.jp/ |
|
フォルダツリーの一部フォルダが表示されなくなる https://forums.mozillazine.jp/viewtopic.php?f=3&t=16304 |
ページ 1 / 1 |
作成者: | WADA [ 2016年9月29日(木) 18:22 ] |
記事の件名: | Re: フォルダツリーの一部フォルダが表示されなくなる |
a5979 さんが書きました: フォルダを作成し使用していた所、急に特定のフォルダがThunderbird上から表示されなくなる現象が発生しました。 「急に」は、ある環境のあるThunderbirdにおいて、長いフォルダー名でも全然問題なく使えていなのに、ある日突然、何も変えてはいないのに、特定のフォルダがThunderbird上から表示されなくなった、ということでしょうか?a5979 さんが書きました: 【環境】 OS :Windows7 Pro SP1 or Windows10 Pro 【調査内容】 (1)フォルダ名の文字数制限 Thunderbirdでは、フォルダの文字列長は250文字まで作成可能 (2)フォルダが非表示になる条件 各フォルダにて、右クリック-[プロパティ]を選択し、[フォルダのプロパティ]を表示し、 [場所]の文字数が582文字までのフォルダは表示される。 583文字以上になると、フォルダが表示されなくなる これだけきちんと調べがついていると、話が早い。 [MSのMAX_PATH関連の話] によると、Win10ではAPIでの長さ制限をなくしたようですね・ コード: Tip Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior. 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文字以内ならばOKになるようになったのかな? a5979 さんが書きました: 対応方法がフォルダ名を短縮する程度しかなく、根本解決が出来てません。 それくらいしか、逃げ道は思いつきません。 なお、IMAPの場合、サーバーから送られてくるMbox名は、Modified UTF-7で(自分でググってください)、そのModified UTF-7の文字列をローカルのファイルのファイル名に使います。 Modified UTF-7ですから、日本語のMbox名だと、ファイル名の文字数が4/3くらいに増えます。 |
作成者: | WADA [ 2016年9月29日(木) 20:52 ] |
記事の件名: | Re: フォルダツリーの一部フォルダが表示されなくなる |
他の逃げ手です。 メールフォルダー用のファイルへのフルパスが長くなる原因の一つは、プロファイルディレクトリーのパスが長くなることです。 普通は、<非常に長いプロファイルディレクトリーのパス>/Imap/<server名>/<メールフォルダー用のファイル> になり、 <非常に長いプロファイルディレクトリーのパス> が下手をすると、256文字の半分くらいを占有してしまうこともあります。 (A) <非常に長いプロファイルディレクトリーのパス> ⇒ C:/TbProf/<random>.default に移動する。 (手動でのprofiles.ini の編集、 新規プロファイルの作成時にC:/TbProf/<random>.defaultを選択、などが要る) (B) アカウントのメールディレクトリーだけを、C:/TbMail/Imap/<server名>に移す。 (ディレクトリーを手動で移動した後、サーバー設定のメッセージの保存先を変える必要がある) 「プロファイルディレクトリーごとコピー・移動」がいつでも効くようにしておくためには、(A)の方がいいでしょう。 いづれにせよ、panacea.dat(万能薬.dat、FolderCacheのデータが入る)に保存されている各Mbox用のファイルのパスが絶対パスである為に、(A)/(B)を行った後の最初のIMAPサーバーへのアクセスでは、サーバーとの同期状態が失われてゼロからのスタートとなって、関係するIMAPアカウントの全メールフォルダーの全メールをサーバーから再度ダウンfロードすることになりますから、巨大なメールフォルダーを愛用している環境では、注意が必要です。 |
作成者: | a5979 [ 2016年9月30日(金) 15:06 ] |
記事の件名: | Re: フォルダツリーの一部フォルダが表示されなくなる |
WADAさん ご返信ありがとうございます。 Linux版ではそのようなバグがあったんですね。 Windowsでも似たような不具合であれば修正に持っていければと考えています。 また、プロファイルディレクトリーのパスを短くするアイデアもありがとうございます。 私だけであれば問題無いのですが、多数のユーザーに影響があるので行うとしても限定的になりそうです。 この現象は他の方は発生していないんでしょうか…。 また、この現象がThunderbirdの不具合の場合はBugzillaに挙げるのが最善なのでしょうか。 |
作成者: | WADA [ 2016年9月30日(金) 16:36 ] |
記事の件名: | Re: フォルダツリーの一部フォルダが表示されなくなる |
a5979 さんが書きました: Linux版ではそのようなバグがあったんですね。 Bug 1093860 は、Filenameの長さが256文字に制限される、という部分についてであって、「260文字 < 500文字とちょっとあたり << path_max」 でパスが切られてしまう、というのは、バグ番号をもう一度見つけられなかった別のバグでした。 Loinux/path_maxだったので、そっちだと即断してしまいました。 a5979 さんが書きました: この現象がThunderbirdの不具合の場合はBugzillaに挙げるのが最善なのでしょうか。 MAX_PATH=260の制限も、昔は、終端のヌルを含んで260バイトだったのが、Unicodeになってから、終端のヌルを含んでUTF-16の260文字、というような変化がありますし、 内部的には、常にUTF-16だけで処理しているわけではなく、UTF-8で行っている場合もあります。 そして、いろいろな場所で、260バイトだったり、260Unicode文字だったり、URF-16は2バイト文字だから260X2バイトだったりと、長さ制限を踏まえて、何らかのワークエリアやバッファーのサイズの制限をしています。 無限に長い文字列を常にサポートするなんてできないですからね。 結局、どこかで260Unicode文字以上を処理できるようにしても、おっつけ、どこかの制限の一番小さなところで切り捨てられるでしょう。 一つボトルネックをつぶせば次のボトルネックがでてくる、で、もぐら叩きみたいなもの(^^) 今回の現象が、Thunderbirdの中の問題なのかOS側の問題なのかはわかりませんが、多くの場合、Thunderbird側の問題でしょうね。 bugzilla.mozilla.orgにバグを開いて、きちんとした問題判別のためのデータを提供して、デベロッパーによる解析を待つ、というのが、正当な手段だと思います。 今までは260文字を超えるとフォルダーが消える、だったのが、 2倍以上の580文字くらいまではフォルダーが消えることなく大丈夫になったんだから、大幅に改善されているわけで、 緊急を要する問題でSeverity=1/Priority=1でこのバグが直るまでは出荷停止、ってなことにはならないと思いますけど。 |
作成者: | WADA [ 2016年9月30日(金) 17:45 ] |
記事の件名: | Re: フォルダツリーの一部フォルダが表示されなくなる |
興味があったので、ちょこっと追試してみました。 以下の、100Unicode文字のメールフォルダーを、Win10上のThunderbirdのダミーのPOP3アカウントに作ってみました。 コード: A123456789B123456789C123456789D123456789E123456789F123456789G123456789H123456789I123456789J123456789 三階層目まではフォルダーを作ることができ、メールのコピーも可能。 (円記号=バックスラッシュはスラッシュに変えてあります) C:/Users/Wada/AppData/Roaming/Thunderbird/Profiles/2vf4qc8s.default/Mail/a.a.a/A123456789B123456789C123456789D123456789E123456f143dd46.sbd/A123456789B123456789C123456789D123456789E123456f143dd46.sbd/A123456789B123456789C123456789D123456789E123456f143dd46.msf 最下層の.msfファイルのパスの長さは、399バイトです。 「~.msfのファイル名」も「~.sbdのディレクトリー名」も、長さは 106バイト。 ローカルフォルダの場合、フォルダー名が128バイトを超していてファイル名がそれ以上になってしまう場合に、 後ろの部分をハッシュして短いファイル名にして、フォルダー名は.msfの中に書く、ということが、今も行われていました。 しかし、以下のディレクトリーの下にそれ以下の階層のフォルダーを作ることは、たとえ半角の「A」であっても、何もしてくれませんでした。 サブフォルダーの作成をリクエストしても、エラーが起こると何の応答も返さずに単に無視、という既知の問題が起こります。 (円記号=バックスラッシュはスラッシュに変えてあります) C:/Users/Wada/AppData/Roaming/Thunderbird/Profiles/2vf4qc8s.default/Mail/a.a.a/A123456789B123456789C123456789D123456789E123456f143dd46.sbd/A123456789B123456789C123456789D123456789E123456f143dd46.sbd/A123456789B123456789C123456789D123456789E123456f143dd46.sbd 最下層のディレクトリーのパスの長さは、399バイトです。 .sbdディレクトリーのパスの長さが259以下なら、その下に、拡張子無しファイル/~.msfファイル/~.sbdディレクトリーを作りに行くが、 .sbdディレクトリーのパスの長さが259を超えているとギブアップ、なのかな? [訂正] 最下層のディレクトリーのパスの長さは、258 Unicode文字、でした。 全角を半角にしてみて、気付いた。 その下のファイルは、/Z (円記号はスラッシュで表示) と、最低限2文字になるので、259文字を超してしまう。 MAX_PATH=260だった頃のままにThunderbirdが自主規制している、ってな感じなのかも。 でも、そうしないと、Win10環境とそれ以外でのメールフォルダーファイルの互換性が失われる。 [訂正おわり] IMAPとローカルフォルダーでは、ファイル名の使い方が異なるので、現象は異なりますが、 Win10になって、APIにおいてはMAX_PATH=260の制限はなくなったが、色々な所のいろいろな長さ制限がまだある訳で、 無限に長いファイルパスになるようなメールフォルダー・メールフォルダーの階層が使えるようになったわけではない、 ということは、言えると思います。 |
作成者: | a5979 [ 2016年9月30日(金) 20:27 ] |
記事の件名: | Re: フォルダツリーの一部フォルダが表示されなくなる |
WADA さん お忙しい中検証まで行って頂きありがとうございます。 258 Unicode文字を超えると発生するとのことですので、こちらで検証した結果と若干異なりますが、 エラーも発生せずフォルダが作成できなくなったとのことですので、現象としては非常に似ていますね。 互換性を考えると、長いフォルダパスを作ることが出来ないとのこと承知しました。 実はExchange Onlineでのメール利用は最近からであり、以前はオンプレでメールサーバーを利用していました。 その頃はもう少し長い文字列だと発生していたようなのですが、Exchange Onlineに変わってエンコードの方式が変わって 文字数が長くなりやすくなってしまったのかもしれませんね。 以前のメールサーバーはまだ生きているので、そちらと同条件で検証し、パスが異なるか確認してみたいと思います。 |
ページ 1 / 1 | All times are UTC + 9 hours |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |