CVE-2014-9390 aka "Git on case-insensitive filesystems" I did not give the…
gitが影響を受けた、HFS+で、一部の文字を区別しなかったり無視したりする問題に対して、Linusが吠えている。
マジで、HFS+はたぶん最悪のファイルシステムだな。クソすぎるぜ。NTFSもutf8の正規化で似たような問題(/の非正規化された表現を使用)があったが、まあ、今は修正されたんだろうよ。OS Xの問題は根本的すぎる。
そりゃ、古いさ。そりゃ、データ保護がクソすぎるってのはあるさ。だが、そういうのは、単に「すげーファイルシステムじゃない」って問題だ。「自分のケツすら拭けないマヌケによって設計された信じがたいクソ」ってわけじゃない。
HFS+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じている人間によって、今もなおクソなファイルシステムとして設計され続けているということだ。
大文字小文字の同一視は信じられないくらいクソなアイディアだ。Appleの連中は修正するべきだがそれをしない。逆に、クソなアイディアを更にくそったれにしてUnicodeに拡張していやがる。UTF-8ですらなく、たぶんUCS2だ。
NTFSも似たようなことをやらかしたが、AppleはHFS+でその上をいくクソをやらかしている。
レガシーモデル(「もっとまともな方法を知らなかった」)における大文字小文字の同一視は、まだいい訳もたつ。だがな、Unicodeの同一性比較がファイルシステムにおいてもいいアイディアだと考えた奴はこの業界から干されるべきだろ。離乳食でもやって部屋の隅っこで邪魔にならないように食わしとけ。そうすりゃ奴らは幸せだろうし、俺らのシステムをクソみたいにしないだろうよ。
そして、NFD正規化を持ちだして、正しいunicodeをクソみたいなフォーマットに変換しやがるとは、言い訳も何もあったもんじゃねえよ。正規化はいいことだと考える奴らすらNFDはクソフォーマットだと認めてるし、データ交換のためにいいフォーマットじゃねーよ。離乳食レベルですらねぇ。設計上、ユーザーのデータをぶっ壊し続けてやがる。クソか。
で、Appleのこういうサルどもにファイルシステムのしごとを任せてるわけか? マジで?
ZFSに移行しなかった妥当な理由は色々ある(オホン、オラクル、ゴホン)にしてもだ、大文字小文字を区別するHFS+に移行させてから、それで将来的にはもっとマシなファイルシステムに移行させることもできただろうが、そいつはしなかったんだよな。大文字小文字を区別する方法があるが、Appleは隠して使わせないようにしている。
アホすぎてやってられねーぜ。
で、クソみたいな方針決定をする奴らと、そのクソを実装する奴らがいる。Johnが文句を言っている「よっしゃ、俺らはまともな機能を実装しないぜ」ってのより、「俺らはクソを実装するぜ」ってほうがはるかにひどい。
文句終わり
まあ、実際HFS+のUnicode正規化はクソだ。
2 comments:
OS Xのファイルシステムのファイル名はNFD正規化でなく「NFD正規化に似た独自の正規化」ではなかったでしょうか。
ただ世の中がNFCばかりなだけで、正規化の観点からはNFDの方がシステマティックに美しい方式だと思います。正規化自体の是非については確かにUnix的な考えには合致しないかも知れないですね
Unicodeのように、分割統治方式じゃなく、一つの空間に全部の文字を組み込む方式で、将来に向けた互換性を維持しようとすると、NFCでは不可能で、NFDにするしかないですからね。
標準のNFDだと、CJK互換文字まで正規化しちゃうため、互換文字を必要とする応用(たとえばOSなんかだと、既存の文字コードとの往復変換が必要なのが普通)だと困るんだけど、CJK互換文字を外したNFDは提案されたことがものの、Unicodeコンソーシアムに却下されたんだとか。
http://www.unicode.org/review/resolved-pri.html#pri7
Apple の modified NFD では、CJK互換文字を対象から外してます
個人的には、大文字小文字の同一視とか、正規化とか一切しない、昔っからのUNIXファイルシステム方式の方が好きなんだけど、WindowsとかOS Xのように、ふつーの人がファイルシステムを直接使うことが要求されるOSだと、そういうわけにはいかないでしょうね。
文字コードの世界は闇だし、Unicodeはその中でも特別に複雑な規格なわけで、Appleの選択にも技術的な必然性はあるわけです。
Post a Comment