Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効化されます。
「RSSの購読が自動に消えてしまう問題」のコメント ( viewtopic.php?f=3&t=15721&p=56492#p56491 ) のスピンオフです。

[例]
mail.server.server#.hostname=x.y.z, mail.server.server#.userName=abc@x.y.z のアカウント(POP3かローカルフォルダ)に「スラド」というサブフォルダを作成し、Thunderbirdの再起動を挟まずに、メッセージフィルタでのコピー先・移動先を「スラド」に設定する。

「ド」
Unicode Character 'KATAKANA LETTER DO' (U+30C9)
U+30C9 , utf-8=0xE38389
Decomposition KATAKANA LETTER TO (U+30C8) COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK (U+3099)
U+30C8 , utf-8=0xE38388
U+3099 , utf-8=0xE38299

msgFilterRules.datのactionValueのmailbox URIは、NFC(composed form)で書かれる。
一方、フォルダーを作成後、再起動を挟んでからメッセージフィルターを定義した時のmsgFilterRules.datのactionValueのmailbox URIは、NFD(decomposed form)で書かれる。

再起動後には、こちらの「NFD(decomposed form)のmailbox URI」が使われるので、メールのコピー先・移動先のフォルダーが見つからなくて、フィルターによるメールのコピー・移動に失敗し、以下のようなエラーが起こり、メッセージフィルタが機能しなくなります。

bugzilla.mozilla.orgにバグを開く時は、ラテン文字でダイアクリティカルマークがある文字で報告した方がいいでしょう。
[例] 「Ü」(U-ウムラウト) 一文字だけのフォルダー名

U+00DC , utf-8=0xC39C
Decomposition LATIN CAPITAL LETTER U (U+0055) COMBINING DIAERESIS (U+0308)
U+0055 , utf-8=0x55
U+0308 , utf-8=0xCC88

NFC(composed form)のmailbox URLNFD(decomposed form)のmailbox URL
[追記]
確認としては、以下が要ると思います。
(0) 「Ü」というフォルダーを作成。
(1) ルール1 : 「Ü」というフォルダーを作成直後、再起動前にフィルターを定義。
(2) 念のためのチェック。
　　ルール2 : 「Ü」以外のフォルダーを数多くクリックしてフォルダーをオープン。
　　フォルダーペインでアカウントの折り畳み・展開を数回行い、しばらく放置。
　　アカウントの折り畳み・展開を数回行い、再起動前にフィルターを定義。
　　アカウントの折り畳み・展開は、フォルダーリディスカバリーを行わせるため。
(3) ルール3 : 再起動後にフィルターを定義。
[追記おわり]

[参考資料]
English terms with diacritical marks
ラテン特殊文字、ダイアクリティカル・マーク
Combining character
Unicode Characters in the Combining Diacritical Marks Block
Wikipedia U-umlaut
Unicode Character 'LATIN CAPITAL LETTER U WITH DIAERESIS' (U+00DC)

[追記]
検索フォルダーの検索対象のケースは、メカニズムはほとんど同じでも、コンポーネントが異なるし、フィルターとは異なりフォルダーのリネームには追随しないし、見つからなかった時は検索対象から黙って外すだけで、それが最後の検索対象のフォルダーだと黙って検索フォルダーを消す、という違いがあります。
bugzilla.mozilla.orgには、フィルターとは別のバグとして開く方がいいでしょう。

検索フォルダー(Virtual Folder。「統合フォルダ」も一つの「検索フォルダー」)においては、プロファイルディレクトリー直下のvirtualFolders.datに、
検索フォルダー自体は、uri=mailbox://nobody@smart%20mailboxes/Archives
検索対象のフォルダーは、scope=mailbox://b1%40b.b.b@b.b.b/Archives | ...
として書かれます。
[追記おわり]

[追記その２]
mailbox URIの形式を見てわかるように、メッセージフィルターのコピー先・移動先のフォルダーのactionValue=のmailbox URI、検索フォルダー自体のuri=のmailbox URI、検索対象のフォルダーのscope=mailbox URI、には、それらの「親のフォルダー」についても含まれますから、
親フォルダーを作り、子フォルダーを作り、再起動を挟まずに、その子フォルダーに関係するメッセージフィルターや検索フォルダーを定義すると、子フォルダー部分だけでなく、親フォルダー部分でも問題が起こり得ます。
[追記その２おわり]

Mac OS Xのpanacea.datの中身の、「スラド」というフォルダーのデータを含む部分。
%エスケープと$エスケープとの違いはあるが、Mac OS Xでもpanacea.datにフルパスが書かれ、HFS+内のNFD(decomposed form)のファイル名が使われていることがわかる。

ローカルメールフォルダーの新規作成

http://mxr.mozilla.org/comm-central/sou ... nds.js#988http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#2345http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsLocalMailFolder.cpp#533http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsLocalMailFolder.cpp#547
フィードと同じCreateLocalSubfolderではなく、パッチと同じCreateSubfolderを使っていて、フィードでCreateSubfolderに変えた時と同様に、nsImsgFolder.URIにはNFC(composed form)がセットされるようです。

nsMsgLocalMailFolderというC++オブジェクトの::CreateSubfolderInternalが作成した、
nsCOMPtr<nsIMsgPluggableStore> msgStore; という、msgFolderオブジェクトを包含するC++オブジェクトが残っているためかな？
だとすると、
(4) ある親フォルダーの下に、濁点や半濁点やウムラウトがあるフォルダーを作成、
　　その親フォルダーの下に、他のフォルダーを作成、
　　(msgStore; という変数の内容が変り、他のフォルダーになる)
　　それから、メッセージフィルターに濁点や半濁点やウムラウトがあるフォルダーを指定、
　　再起動。
あたりが有効？

以下を、言語=Shift_JISの日本語 MS Win XPで試したら、失敗。
(A) 「Ü」(Uウムラウト一文字だけ)のフォルダー名
Shift_JISに「Ü」は無いから、不正なファイル名の文字としてed9f485f.msf/ed9f485fというファイルを作るので、msgFilterRules.datやvirtualFolder.datには、ed9f485fでmailbox URIが書かれてしまう。
ed9f485f.msfの中には、「(85=$C3$9C)」という「Ü」(Uウムラウト一文字だけ)の実際のフォルダー名が保持される。

(B) 「U＋ウムラウト」(Uとウムラウトのニ文字)のフォルダー名
フォルダー名指定のダイアログでは、「U」の後に「ウムラウト」をペーストすると、フォルダー名指定のダイアログでの表示が「Ü」に変わる。
しかし、「フォルダー名」としては「Uとウムラウトのニ文字」であり、
Shift_JISに「Uとウムラウトのニ文字」は無いから、不正なファイル名の文字として3fcd87ad.msf/3fcd87adというファイルを作るので、msgFilterRules.datやvirtualFolder.datには、3fcd87adでmailbox URIが書かれてしまう。
3fcd87ad.msfの中には、「(85=U$CC$88)」という「Uとウムラウトのニ文字」の実際のフォルダー名が保持される。

フォルダーペインやフォルダーピッカーでは、どちらも「Ü」と表示されるし、フォルダーのプロパティーの「場所」を見ても「ed9f485f.msf」か「3fcd87ad.msf」が表示されるだけだから、どっちがどっちかはそう簡単には区別できない。
UIではNFC(composed form)だけを使い、NFD(decomposed form)でわざわざ指定するなんてアホなことはしてはいけません、ということでしょう。

OS　XのRSS問題でattachment 8684700を試してみたついでにローカルフォルダの挙動についても見てみました。
「ダイアクリティカルマーク有りがよろし」というお話だったので、フォルダの名前は「Ü」で確認しています。

再起動前にフィルターを定義した場合のmsgFilterRules.datでは


再起動後にフィルターを定義した場合は


patch済でも変わらず再現するようです。
また、

これは、最初の「濁点や半濁点やウムラウトがあるフォルダーを作成」から「メッセージフィルターに濁点や半濁点やウムラウトがあるフォルダーを指定」まで一度も再起動を挟まない、という前提でよいでしょうか？
その理解で行ってみると、

とNFCで書かれてしまい、再起動後にフィルターが動かなくなります。

具体的な手順を書くと、

1. 添付画像のフィードアカウント「Um」についてスラドのRSSを購読中
2. 新規フォルダ「Um」を作成
3. その下にサブフォルダ「Ü」を作成
4. 「Um」の下に別のフォルダ「ウー」を作成
5. メッセージフィルタのコピー先として「Ü」を指定
6. 再起動

で行っています。（2-5の間に再起動を挟まない）

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

確認ありがとうございます。

同じ親フォルダーの下に他のフォルダーを作っても、関係無さそうですね。
各メールフォルダーは、フォルダーペインやフォルダーピッカーに表示されますし、新規作成後にはメールフォルダーがオープンされますから、一度nsImsgFolderのオブジェクトが作られると、Tbの終了まで消されない、と見てよさそうです。

必要なテストは、(1)メールフォルダー作成後、再起動前にフィルターを定義、(2)フォルダー作成後、再起動してからフィルターを定義、だけみたいですね。

なお、フィードの場合は、フィードのオブジェクト.folderにnsImsgFolderへの参照を保持しますが、メールフォルダーの場合には、それはありません。
CreateLocalSubfolder(フィードで使用)もCreateSubfolder(メールフォルダーと一部のパッチをあてたフィードで使用)を使うという点では同じですが、コンポーネントも処理しているコードも異なりますから、メールフォルダーでのテストとフィードでのテストは、完全に分離してください。
「Ü」というメールフォルダー、というのは、メールフォルダーのフィルターについてバグを報告した後、再現テストやパッチのテストをヨーロッパの連中に行わせるためです。

前にも言いましたが、フィードのパッチはフィードのコードだけの変更であり、CreateLocalSubfolder/CreateSubfolderなどは共通に使われてはいても、パッチは、メールフォルダーの作成とは一切関係ありません。
バグを報告したあとの混同・混乱を避けるために、メールフォルダーのケースは、リリースバージョンのTb 38での再現テストにしてください。

createLocalSubfolder(nsImsgFolderを返す)もcreateSubfolder(nsImsgFolderを返さない)も、最後はCreateSubfolderInternalをコールします。
http://mxr.mozilla.org/comm-central/sou ... er.cpp#547
547 nsMsgLocalMailFolder::CreateSubfolderInternal(const nsAString& folderName,
で、CreateSubfolderInternalは、nsMsgBrkMBoxStore::CreateFolderをコールします。
http://mxr.mozilla.org/comm-central/sou ... ore.cpp#69
69 NS_IMETHODIMP nsMsgBrkMBoxStore::CreateFolder(nsIMsgFolder *aParent,
この中で、親フォルダー用のディレクトリーの下にファイルを作り、nsImsgFolderオブジェクトを作り、xxx.msfファイルも作ってメールフォルダーとしてオープンし、msgDatabaseオブジェクトを作ります。
これには、msgStore=Maildir版もあります。

本質的な解決は、このmsgStoreのCreateFolderでファイルを作った直後に、再起動後と同様に、Mac OS X上では、HDD上のフォルダー用のファイルの実際の名前からnsImsgFolder.URIをセットする、になると思います。
こうすれば、フィードのコードの変更は不要になります。
しかし、これだと、多分、結構大きな変更になりそうな気がします。
フィードで行おうとしているように、
mailbox URIとしてnsImsgFolderURIのデータを使うときは、常にNFC(composed form)に変換して使い、
Mac OS X上でmailbox URIからメールフォルダーを見つける時には、NFC(composed form)で探して無ければNFD(decomposed form)で探す、という方が、
たとえ変更箇所は多くなっても、変更自体はシンプルなものになるように思います。

でも、nsMsgBrkMBoxStore::CreateFolderは、ファイルを作った後、親のmsgDBのAddSubfolderをコールしています。
103 rv = aParent->AddSubfolder(safeFolderName, getter_AddRefs(child));

http://mxr.mozilla.org/comm-central/sou ... r.cpp#3689
3689 NS_IMETHODIMP nsMsgDBFolder::AddSubfolder(const nsAString& name,
この中で、HDD上の実際のファイル名ではなく、指定されたフォルダー用のファイル名で、URIを生成しているように見えます。
このステップで、Mac OS Xの時には、ファイルシステム上の(HFS+)実際のファイル名からURIを生成すれば、一件落着、のようにも思えます。

すみません。確かにおっしゃる通りですね。
後からこのトピックを読む方が混乱しないように、

• 再起動前にフィルターを定義した場合のmsgFilterRules.datでは、actionValue=にNFCの文字列が書かれる
• 再起動後にフィルターを定義した場合には、actionValue=にNFDの文字列が書かれる

これらの現象は素のThunderbird38.3.0で起こることを確認しています。
と明記しておきます（実際に確認をとりました）。

それと、もう少しこの現象を調べてみると、フォルダペイン上において、

• 新規フォルダを作成直後（再起動前）のフォルダ名はNFC
• 新規フォルダを作成後、再起動した後のフォルダ名はNFD

になっています。
これは以下のように調べました。

添付画像の上部(アカウント名：スラド）のサブフォルダにあるÏ、Üのフォルダは、作成後に再起動済みの状態です。
これを、「フォルダの情報を見る」よりフォルダ名をコピーし、画像下部のアカウント（Vanilla）にコピーした名前で新規にフォルダを作成
再起動せずにVanilla内の「Ï」「Ü」フォルダをコピー先にしたメッセージフィルタを定義すると、それぞれ

となり、フィルタ定義後に再起動をしてもフィルタは有効なままです。

一方で、同じようにフォルダ名をコピーするのであっても、フォルダ作成後再起動前の状態からコピーした場合は、

となり、再起動後はフィルタが無効化されます。
（上記フォルダは、添付画像作成後にスラドのアカウント内に「Ë」で作成したフォルダ名を、Vanillaの新規フォルダ名としてコピーしたものです。
メッセージフィルタはVanilla内の「Ë」をコピー先にしています）。

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

フォルダーペインでのフォルダー名は、nsIMsgFolder.prettiestNameから持ってこられるから、
(A) nsIMsgFolder.URIがNFCなら、prettiestNameもNFC、
nsIMsgFolder.URIがNFDなら、prettiestNameもNFD、
ということでしょう(prettiestNameがURIに反映される、という方が、正確かもしれない)。
フォルダーペインのUIでの表示においては、NFCへの変換が入るから、どちらも同じグリフで表示されますけど。
そして、(B) Mac OS XのHFS+では、NFCの名前でファイルを作成しても、NFDの名前でファイルを作成しても、ファイルシステム内ではNFDのUTF16でファイル名が保存されるから、NFCの名前のファイルとNFDの名前のファイルは、OS上/ファイルシステム上は全く同じもの、と言えるはずです。

フォルダー名/ファイル名の比較は、私のWin/システムの文字セット=Shift_JISでの時と同様に、NFC⇔NFDの変換を行わずに比較していると思います。
NFCの名前でメールフォルダーを作ったすぐ後、再起動の前に、NFDの名前でメールフォルダーを作ろうとすると、
Thunderbirdは、重複する名前は無い、として、ファイルを作ろうとして、
ファイルシステム上で既にファイルが存在するのでファイルの作成に失敗し、
エラーの時に何もメッセージを出さないから、
単に、NFDの名前でメールフォルダーを作ろうとしても何も起こらない、という現象になるような気がします。
NFCのフォルダー名 ⇔ NFCのフォルダー名 のリネームでも、多分、似たような現象になりそう。

「U」+「ウムラウト」の入力は、「U」をタイプし、参考資料のU+0308のWebページから「ウムラウト」の文字をコピー＆ペースト、が簡単。
http://www.fileformat.info/info/unicode ... ertest.htm
「U+0308」でググれば直ぐにたどりつけます。
フォルダー名の入力フィールドでは、「U」の後ろに「ウムラウト」の文字をコピー＆ペーストすると、「U」の表示が「Ü」の表示に変ると思いますが、フォルダー名のデータとしては、「U」+「ウムラウト」のままのはずです。

フィードのフォルダーも、購読しているURLから持ってきたデータを元にメールの形式のデータを作って、ローカルのメールフォルダーに書いているだけであって、
メッセージフィルター・検索フォルダーにとって、普通のローカルのメールフォルダー(POP3、ローカルフォルダ)と何ら変りありません。
しかし、バグに提供するデータとしては、Feedsの下のフォルダーだと、再現テストのために購読をする作業が必要などの余計なことがいるし、下手をすると、フィード特有の問題などが同時に起こったりして、混乱を招きかねません。
ダミーのPOP3アカウントを定義し(存在しないサーバーを指定)、サーバー名=x.y.z、ユーザー名=a、とすれば、mailbox URLが、
mailbox://a@x.y.z/ParentFolder/FolderName
となって、データも短くできて、可読性も上がります。

このトピックでのデータの提示は、フィードのテストのついでのフィードのフォルダーでの結果でかまいませんが、
メッセージフィルター・検索フォルダーのケースについてバグを開いた後に提示するデータは、フィードのフォルダーを避けてくださるよう、お願いします。

ただし、フィード・メッセージフィルター・検索フォルダーの本質的な違いは、以下の違いだけであって、
　フィード: nsIMsgFolder.URIの値を、feeds.rdfに書く
　メッセージフィルター: nsIMsgFolder.URIの値を、msgFilterRules.datに書く
　検索フォルダー: nsIMsgFolder.URIの値を、virtualFolders.datに書く
ファイルの作成・オープンに関係する、nsLocalFileUnix.cppでの修正、
nsIMsgFolder.URIの値をセットできる、nsMsgDBFolder::AddSubfolderなどでの修正、
もあり得ますから、
現時点では、フィードのバグの中で、共通の、これらのコードでの変更を模索中です。
従って、メッセージフィルター・検索フォルダーのケースについては、まだバグを開いていません。

WADAさん

申し訳ありませんがこの件からは手を引きます。
検証後に「○○のデータでは駄目、××でないと」という「条件後出し」の状況が続けば、いわゆる「手戻り」が増えて時間も手間も無駄にかかります。

もちろん、これは当方の無知浅慮によるところも大きいのですが、検証条件としてどのようなものが望ましいか、当方の浅薄な知識と技量では「事前には」読み取れませんでした。
例）
未patchかpatch済みか
フィードアカウントで良いのかメールアカウントにすべきか
フィード購読の場合とローカルのフォルダの具体的な違い

「検証条件：以下××」などと明記されていないものも含めてちゃんと読み取るべき
Thunderbirdの内部構造も全て把握の上で行うべき
ということであれば、明らかに当方の技量の範囲を超えていますし（以前も書きましたが、プログラム本体やソースコードに関する内容はわかりません）、既に再現条件もはっきりしているものであるので、きちんとThunderbirdの内部構造やソースコードの記述も含めて理解されている方々にお任せしたいと思います。
Bugzillaでの引用もしていただいていることですし。

お役に立てず申し訳ありません。

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

んじゃ、私も、フィードの件からも、このトピックの件からも、バグからも、一切手を引くとします。
乗りかかった船、ということで、バグなどのフォローもしてましたけど、私はMac OS Xユーザーではないし、別に、Mac OS Xの上で何が起ころうが、私には一切関係はありません。
後は、Mac OS X/Thunderbirdユーザーの間で、お好きなように。

あまり売り言葉に買い言葉とはしたくないのですが。

まず、今までのWADAさんの助力には大変感謝しています。
前トピック「RSSの購読が自動に消えてしまう問題」から、長きにわたり問題の検証やBugzillaでのやりとり、フィードバックやこちらのフォーラムでのサポートなど、幾度となく支えて頂きありがとうございます。

言い訳めいてしまいますが、当方も厳密に言うと「ユーザ」ではありません。OS X環境ではありますが、フィードの購読や管理は別のアプリケーションで行っているため、Thunderbird上で本格的にフィードを使っているわけではないです。

前トピックの「RSSの購読が自動に消えてしまう問題」にて、当初「再現しないよ？」という雰囲気だったため、「ほんとにOS Xで再現するのかな」と確認兼ねてやってみたのがはじまりです。
その後、feeds.rdfの確認や各種設定ファイルにかかれる文字列の話題に発展し、そのまま「乗りかかった船」で確認や検証を行っていました。

それで前便に書いた文章についてですが、

一つ目、patchの話は、前トピックにあるお願い文と本トピックのこれ、二つ目と三つ目も本トピックの内容です。
改めて両トピックの全文を読み返してみましたが、必要な検証条件が事前に明記されている部分は探せませんでした（当方の読解力がアレなのかもしれませんが…）。

「いちいち言わなくてもわかるよね」ということなら、本来そうなのかもしれませんが、そのあたりの行間や背景事情まで適切に読み取れるだけの技量が、残念ながら当方にはございません。

「そちらが勝手にやった事だろう」ということであれば、「勝手に突っ走ってしまい申し訳ありません」と平謝りするしかありませんが、
・やってみました→それじゃない、こっち
・patch後で検証しました→未patchでないと…
といったことが、やった「後」から小出しで指摘され、しかもそれが何度も続くと正直心折れますし、「じゃぁ指示あるまで動かないのが正解」と完全受け身になりますが、そういう方が望ましいということでしょうか。

もし「細かく言わなくても、ちゃんとこちらの意図を汲んで望ましい条件の検証を行ってよ」ということであれば、そのあたりの詳細な知識と技術をお持ちの方に検証・修正をお任せしたほうが、不慣れな当方が躓きながら行うよりも、よりスピーディーでスムーズに進むのではないかと思い、あの文章を書きました。
けして非難や蔑む意図ではないことをご理解ください。

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

私の方は、meeyarさんからの的確なMac OS X上での実際のデータの提供がないのならばバグのフォローなどの一切がもうできない・する気も無い、ということをご理解ください。

フィードのパッチをあてた時云々、に関しては、meeyarさんが、ちょっと誤解しているかな、という点を、ちょっと修正しただけ。
このトピックでのデータの提示ならば、私はある程度理解しているからいいし、
バグの中で説明する時には、全て、meeyarさんからのMac OS X上での実際の的確なデータをベースにしています。
良くわかっていない人に説明する時とか、bugzilla.mozilla.orgのバグで、feedのバグの時のようにデータをバグに添付してもらう時には、混乱・混同が起こらないように注意してね、ということを書いただけ。
再現テストやパッチのテストを、ヨーロッパの連中にもやってもらわないと、たまったもんじゃない。
フィードのバグでは、日本のフィードでの問題だから、誰も再現テストなんてしてくれなかったでしょ？
任意のフィードで、フィードのフォルダーを、「ド」とか「ブ」とか「Ë」とか「Ü」にリネームすりゃぁ簡単に現象を見られる、と書いたって、実際のフィードでの現象ではないから、誰も再現テストやパッチのテストなんてしてくれない。
そして、このフォーラムのフィードのトピックにしろこのトピックにしろ、「的確なMac OS X上での実際のデータ」はmeeyarさんからしか提供されなかった、というのは、厳然たる事実でしょ？