― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

返信する
ユーザー名:
件名:
オプション:
BBCode: ON
[img]: ON
[flash]: OFF
[url]: ON
スマイリー: ON
BBCode を無効にする
フォントサイズ:
フォントカラー
スマイリーを無効にする
URL を自動的にパースしない
ユーザエージェントを表示する
認証コード
KCaptcha by Nikita_Sp
   

トピックのレビュー - Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効化される
作成者 メッセージ
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
みなさまへ
長らく放置状態、かつご心配をおかけして申し訳ありません。
当方の言い方がきつく、流れを壊してしまいすみませんでした。

ただ、正直検証が一人だと荷が重いのは事実です。
もちろん他の方々にも入って頂けるのであれば大歓迎ですが、Bugzilla周りの活動や動作検証などをメインとして動くのならば、このフォーラムよりもBugzilla-jpなどの方がよいようにも思いました。
検証可能な知識や技術を持った方が集まりやすそうという意味でも。
投稿記事 Posted: 2015年12月09日(水) 23:32
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
横から失礼します。

WADAさんはMac OS Xの環境が無い状態で技術的な検証をされていて、meeyarさんは実際の環境でテストされているんですよね?
お互い補い合ってテストしているようですから、多少の行き違いがあっても仕方ありません。

個人的には、このトピックは続けていただきたいです。
クールダウンして、余裕のある時に続けられてはいかがですか?
もちろん、他の方も検証に加わってくださるのも良いと思います。
投稿記事 Posted: 2015年11月17日(火) 11:39
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
どうしても「修正が頓挫するのはおめーが手を引くからであって、そっちが悪い」の論調にしたいのですね。こちらとしては、殴り合いの展開にはしたくないのですけれども。

まず根本的に、「他の方に助力してもらわないと何もできない」というのであれば、必要な情報や設定ファイルの記述内容について、「これを守ってほしい、この条件が望ましい」という前提条件が不明瞭すぎです。
WADA さんが書きました:
フィードのパッチをあてた時云々、に関しては、meeyarさんが、ちょっと誤解しているかな、という点を、ちょっと修正しただけ。
このトピックでのデータの提示ならば、私はある程度理解しているからいいし、
バグの中で説明する時には、全て、meeyarさんからのMac OS X上での実際の的確なデータをベースにしています。
良くわかっていない人に説明する時とか、bugzilla.mozilla.orgのバグで、feedのバグの時のようにデータをバグに添付してもらう時には、混乱・混同が起こらないように注意してね、ということを書いただけ。

当方は「良くわかっていない人」には入らないのか……随分と買いかぶられてますね。

「修正しただけ」とおっしゃいますが、修正が必要となるほどの前提条件は事前に開示はして頂けないのでしょうか?
WADAさんがどのようにこの問題をとらえ、どのようなアプローチで本件を解決しようとお考えなのかは、他の人からは「文字で書かれたもの」でしかわかりません。膨大な知識や技術がある方の頭の中では、壮大なロードマップが築かれているのかもしれませんが、「書かれていない事柄、背景については他所からは知りえない」という当たり前の事実を認識してください。

今の状況ですと、寸劇風に書けば
ラーメン食べたい>(´▽`*)
(*・∀・)つ<できましたー
えっ醤油なの? 味噌がよかったのに…>(´・ω・`)
(・o・).o(えっ、初めに味を言ってくれればよかったのに…

といった状況なのですね。
Aの条件でやってみました→それちげーよ、Bでやらないと
というのが、「すべて」後からわかった話なわけです。
実行前には具体的な要件が不明なまま、行ってしまった「後」で、「ふつう味噌作るよね、醤油じゃなくて」といった事例が続けば、とてもその後のモチベーションを保てそうにありません。

WADAさんの頭の中では、「当然この条件で行うべきもの」と了解済みになっている事柄でも、こちらにしてみれば、「知らない、初耳」であるわけです。
そして、実際に修正ややり直しが必要となれば、それまでに行ったことが無駄になってしまいます。
「やり直しの手間なんて大したことないよね?」の立場でしょうか?

「改めて言われないとわからないなんて、そちらの浅学が悪い」
と言われれば、返す言葉もありませんが、そうであれば尚更、
細かい説明をせずともきちんと全体像を理解できる知識と技術のある方に入って頂く
WADAさんのお考えをリアルタイムで正確詳細に把握できる、チャネリングに長けた方の協力を仰ぐ
などとしたほうが、時間も手間も無駄にならないと思います。

それから、確かに前トピックから継続して確認・検証を行っていますが、元々のトピックをたてた最初期の方々や、直接Bugzillaへ報告された方は別にいらっしゃいます。
当方がこのまま継続/中断のいずれになったとしても、トピックの当事者の皆さまが今回のことでどのようにお考えなのかは別の話ですよ。
投稿記事 Posted: 2015年11月16日(月) 20:17
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
meeyar さんが書きました:
けして非難や蔑む意図ではないことをご理解ください。

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

フィードのパッチをあてた時云々、に関しては、meeyarさんが、ちょっと誤解しているかな、という点を、ちょっと修正しただけ。
このトピックでのデータの提示ならば、私はある程度理解しているからいいし、
バグの中で説明する時には、全て、meeyarさんからのMac OS X上での実際の的確なデータをベースにしています。
良くわかっていない人に説明する時とか、bugzilla.mozilla.orgのバグで、feedのバグの時のようにデータをバグに添付してもらう時には、混乱・混同が起こらないように注意してね、ということを書いただけ。
再現テストやパッチのテストを、ヨーロッパの連中にもやってもらわないと、たまったもんじゃない。
フィードのバグでは、日本のフィードでの問題だから、誰も再現テストなんてしてくれなかったでしょ?
任意のフィードで、フィードのフォルダーを、「ド」とか「ブ」とか「Ë」とか「Ü」にリネームすりゃぁ簡単に現象を見られる、と書いたって、実際のフィードでの現象ではないから、誰も再現テストやパッチのテストなんてしてくれない。
そして、このフォーラムのフィードのトピックにしろこのトピックにしろ、「的確なMac OS X上での実際のデータ」はmeeyarさんからしか提供されなかった、というのは、厳然たる事実でしょ?
投稿記事 Posted: 2015年11月16日(月) 02:45
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
あまり売り言葉に買い言葉とはしたくないのですが。

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

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

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

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

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

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

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

もし「細かく言わなくても、ちゃんとこちらの意図を汲んで望ましい条件の検証を行ってよ」ということであれば、そのあたりの詳細な知識と技術をお持ちの方に検証・修正をお任せしたほうが、不慣れな当方が躓きながら行うよりも、よりスピーディーでスムーズに進むのではないかと思い、あの文章を書きました。
けして非難や蔑む意図ではないことをご理解ください。
投稿記事 Posted: 2015年11月16日(月) 00:28
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
meeyar さんが書きました:
WADAさん
申し訳ありませんがこの件からは手を引きます。

んじゃ、私も、フィードの件からも、このトピックの件からも、バグからも、一切手を引くとします。
乗りかかった船、ということで、バグなどのフォローもしてましたけど、私はMac OS Xユーザーではないし、別に、Mac OS Xの上で何が起ころうが、私には一切関係はありません。
後は、Mac OS X/Thunderbirdユーザーの間で、お好きなように。
投稿記事 Posted: 2015年11月15日(日) 21:53
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
WADAさん

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

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

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

お役に立てず申し訳ありません。
投稿記事 Posted: 2015年11月15日(日) 19:58
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
meeyar さんが書きました:
コード:
actionValue="mailbox://nobody@Feeds-6/I%CC%88"
actionValue="mailbox://nobody@Feeds-6/U%CC%88"

フィードのフォルダーも、購読している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などでの修正、
もあり得ますから、
現時点では、フィードのバグの中で、共通の、これらのコードでの変更を模索中です。
従って、メッセージフィルター・検索フォルダーのケースについては、まだバグを開いていません。
投稿記事 Posted: 2015年11月15日(日) 12:57
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
meeyar さんが書きました:
これを、「フォルダの情報を見る」よりフォルダ名をコピーし、画像下部のアカウント(Vanilla)にコピーした名前で新規にフォルダを作成
再起動せずにVanilla内の「Ï」「Ü」フォルダをコピー先にしたメッセージフィルタを定義すると、それぞれ
コード:
actionValue="mailbox://nobody@Feeds-6/I%CC%88"
actionValue="mailbox://nobody@Feeds-6/U%CC%88"

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

一方で、同じようにフォルダ名をコピーするのであっても、フォルダ作成後再起動前の状態からコピーした場合は、
コード:
actionValue="mailbox://nobody@Feeds-6/%C3%8B"

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

フォルダーペインでのフォルダー名は、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」+「ウムラウト」のままのはずです。
投稿記事 Posted: 2015年11月15日(日) 09:36
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
WADA さんが書きました:
前にも言いましたが、フィードのパッチはフィードのコードだけの変更であり、CreateLocalSubfolder/CreateSubfolderなどは共通に使われてはいても、パッチは、メールフォルダーの作成とは一切関係ありません。
バグを報告したあとの混同・混乱を避けるために、メールフォルダーのケースは、リリースバージョンのTb 38での再現テストにしてください。

すみません。確かにおっしゃる通りですね。
後からこのトピックを読む方が混乱しないように、
  • 再起動前にフィルターを定義した場合のmsgFilterRules.datでは、actionValue=にNFCの文字列が書かれる
  • 再起動後にフィルターを定義した場合には、actionValue=にNFDの文字列が書かれる
これらの現象は素のThunderbird38.3.0で起こることを確認しています。
と明記しておきます(実際に確認をとりました)。

それと、もう少しこの現象を調べてみると、フォルダペイン上において
  • 新規フォルダを作成直後(再起動前)のフォルダ名はNFC
  • 新規フォルダを作成後、再起動した後のフォルダ名はNFD
になっています。
これは以下のように調べました。

添付画像の上部(アカウント名:スラド)のサブフォルダにあるÏ、Üのフォルダは、作成後に再起動済みの状態です。
これを、「フォルダの情報を見る」よりフォルダ名をコピーし、画像下部のアカウント(Vanilla)にコピーした名前で新規にフォルダを作成
再起動せずにVanilla内の「Ï」「Ü」フォルダをコピー先にしたメッセージフィルタを定義すると、それぞれ
コード:
actionValue="mailbox://nobody@Feeds-6/I%CC%88"
actionValue="mailbox://nobody@Feeds-6/U%CC%88"

となり、フィルタ定義後に再起動をしてもフィルタは有効なままです。
添付ファイル:
コメント: 赤枠はフォルダ作成後再起動済み
namecopy.png
namecopy.png [ 41.67 KiB | 表示数: 10978 回 ]


一方で、同じようにフォルダ名をコピーするのであっても、フォルダ作成後再起動前の状態からコピーした場合は、
コード:
actionValue="mailbox://nobody@Feeds-6/%C3%8B"

となり、再起動後はフィルタが無効化されます。
(上記フォルダは、添付画像作成後にスラドのアカウント内に「Ë」で作成したフォルダ名を、Vanillaの新規フォルダ名としてコピーしたものです。
メッセージフィルタはVanilla内の「Ë」をコピー先にしています)。
投稿記事 Posted: 2015年11月14日(土) 19:55
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
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を生成すれば、一件落着、のようにも思えます。
投稿記事 Posted: 2015年11月13日(金) 13:13
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
meeyar さんが書きました:
再起動前にフィルターを定義した場合のmsgFilterRules.datでは
コード:
actionValue="mailbox://nobody@Feeds-4/%C3%9C"
再起動後にフィルターを定義した場合は
コード:
actionValue="mailbox://nobody@Feeds/U%CC%88"
確認ありがとうございます。

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

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

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

meeyar さんが書きました:
patch済でも変わらず再現するようです。
前にも言いましたが、フィードのパッチはフィードのコードだけの変更であり、CreateLocalSubfolder/CreateSubfolderなどは共通に使われてはいても、パッチは、メールフォルダーの作成とは一切関係ありません。
バグを報告したあとの混同・混乱を避けるために、メールフォルダーのケースは、リリースバージョンのTb 38での再現テストにしてください。
投稿記事 Posted: 2015年11月13日(金) 09:08
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
OS XのRSS問題でattachment 8684700を試してみたついでにローカルフォルダの挙動についても見てみました。
「ダイアクリティカルマーク有りがよろし」というお話だったので、フォルダの名前は「Ü」で確認しています。
WADA さんが書きました:
確認としては、以下が要ると思います。
(0) 「Ü」というフォルダーを作成。
(1) ルール1 : 「Ü」というフォルダーを作成直後、再起動前にフィルターを定義。
(2) 念のためのチェック。
  ルール2 : 「Ü」以外のフォルダーを数多くクリックしてフォルダーをオープン。
  フォルダーペインでアカウントの折り畳み・展開を数回行い、しばらく放置。
  アカウントの折り畳み・展開を数回行い、再起動前にフィルターを定義。
  アカウントの折り畳み・展開は、フォルダーリディスカバリーを行わせるため。

再起動前にフィルターを定義した場合のmsgFilterRules.datでは
コード:
actionValue="mailbox://nobody@Feeds-4/%C3%9C"

WADA さんが書きました:
(3) ルール3 : 再起動後にフィルターを定義。

再起動後にフィルターを定義した場合は
コード:
actionValue="mailbox://nobody@Feeds/U%CC%88"


patch済でも変わらず再現するようです。
また、
WADA さんが書きました:
(4) ある親フォルダーの下に、濁点や半濁点やウムラウトがあるフォルダーを作成、
  その親フォルダーの下に、他のフォルダーを作成、
  (msgStore; という変数の内容が変り、他のフォルダーになる)
  それから、メッセージフィルターに濁点や半濁点やウムラウトがあるフォルダーを指定、
  再起動。

これは、最初の「濁点や半濁点やウムラウトがあるフォルダーを作成」から「メッセージフィルターに濁点や半濁点やウムラウトがあるフォルダーを指定」まで一度も再起動を挟まない、という前提でよいでしょうか?
その理解で行ってみると、
コード:
actionValue="mailbox://nobody@Feeds-5/Um/%C3%9C"

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

具体的な手順を書くと、
  1. 添付画像のフィードアカウント「Um」についてスラドのRSSを購読中
  2. 新規フォルダ「Um」を作成
  3. その下にサブフォルダ「Ü」を作成
  4. 「Um」の下に別のフォルダ「ウー」を作成
  5. メッセージフィルタのコピー先として「Ü」を指定
  6. 再起動
で行っています。(2-5の間に再起動を挟まない)


添付ファイル:
umlaut.png
umlaut.png [ 14.52 KiB | 表示数: 11147 回 ]
投稿記事 Posted: 2015年11月12日(木) 23:21
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
以下を、言語=Shift_JISの日本語 MS Win XPで試したら、失敗。
コード:
[例] 「Ü」(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

(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)でわざわざ指定するなんてアホなことはしてはいけません、ということでしょう。
投稿記事 Posted: 2015年11月12日(木) 02:16
  記事の件名:  Re: Mac OS Xで、メッセージフィルターのコピー先・移動先が濁点などがあるフォルダーだと、再起動後にルールが無効  引用付きで返信する
ローカルメールフォルダーの新規作成

http://mxr.mozilla.org/comm-central/sou ... nds.js#988
コード:
988 case "cmd_newFolder":
989 gFolderTreeController.newFolder();
990 break;
http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#2345
コード:
2345 newFolder: function ftc_newFolder(aParent) {
2367 if (aName)
2368 aFolder.createSubfolder(aName, msgWindow);
http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsLocalMailFolder.cpp#533
コード:
533 nsMsgLocalMailFolder::CreateSubfolder(const ...
536 nsresult rv = CreateSubfolderInternal(folderName, msgWindow, getter_AddRefs(newFolder));
http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsLocalMailFolder.cpp#547
コード:
547 nsMsgLocalMailFolder::CreateSubfolderInternal(const nsAString& folderName,

555 nsCOMPtr<nsIMsgPluggableStore> msgStore;
556 rv = GetMsgStore(getter_AddRefs(msgStore));
557 NS_ENSURE_SUCCESS(rv, rv);
558 rv = msgStore->CreateFolder(this, folderName, aNewFolder);

フィードと同じCreateLocalSubfolderではなく、パッチと同じCreateSubfolderを使っていて、フィードでCreateSubfolderに変えた時と同様に、nsImsgFolder.URIにはNFC(composed form)がセットされるようです。

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

All times are UTC + 9 hours


ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean