パスワードを忘れた? アカウント作成
6274 story

Pantherのファイルシステムは大文字小文字を区別する? 14

ストーリー by yourCat
Case-sensitiveの和訳にいつも悩む 部門より

Acanthopanax 曰く、 "MacBidouilleの記事“MAC OS Case sensitive” (英語版) によると、Mac OS X 10.3 (Panther)のベータ版には、Mac OS拡張フォーマット (HFS+) でも大文字小文字の区別をするようにするというオプションがあるという。HFS+ではファイル名の大文字と小文字を記録はするものの区別しないために、過去にはApacheにセキュリティ上の問題が発生したこともある。また、nkfのmakeの際に、ファイル名が衝突してうまくビルドできないという事例もあった。まだ噂の段階だが、実装されれば、UNIX由来のソフトウェアを移植するには便利になるかもしれない。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • もしも本当であるとしれば素晴しい話ですね。

    でも実際のところ内部ではどうやって処理することで区別できるように
    するんでしょうか?
    現行のHFS+ではどうやっても区別できそうにはないんですが…
    何かメタデータを作ってリソースフォークに埋め込んだりして区別するのだろうか。
    いずれにしても興味深いです。

    # これで py-gtk を入れるのが楽になる…
    • HFS+は元々区別してますよ
      現状で比較判断しないだけ
    • 初心者の質問なんですが
      もともとASCIIコードが大文字と小文字が違いますよね。
      だからMacのファイルシステムは大文字のコードと小文字のコードを同じものと見なすルーチンがあるのだと思っていました。

      だから大文字と小文字を見分けられるようにするのは技術的には簡単なんではないのですか?
      • もともとASCIIコードが大文字と小文字が違いますよね。

        だからMacのファイルシステムは大文字のコードと小文字のコードを同じものと見なすルーチンがあるのだと思っていました。

        HFS+は仕様では名前をUnicodeで扱うことになってます。
        そのためUS-ASCIIだとかShift_JISとかいったバイト列のレベルの概念ではUnicode文字は扱いません
        もちろんUTF-8バイト列でも、バイト単位での比較もできません。

  • by ababincho (14851) on 2003年08月07日 0時04分 (#373650)
    実現されればとても嬉しいです。
    速度がまったく違うことや、HFS+ でないと動かないソフトが多々あることでHFS+ を使っていますが、この大文字小文字の問題では、細かいことで結構苦労させられていましたので。

    UFS2 になって、速度があがればそっちかな、と思っていました。

    ところで、HFS and HFS Plus in FreeBSD [freebsd.org]というのがあるそうですが、これはどうなんでしょう。
  • by Anonymous Coward on 2003年08月06日 15時30分 (#373242)
    濁音付きの字は区別されていませんね。
    「が(0xE3, 0x81, 0x8C)」
    「か(0xE3, 0x81, 0x8B)」+「濁点(0xE3, 0x82, 0x99)」

    touch "が" なんてすると分かります。
    これは問題にならない?
    • Re:日本語でも (スコア:1, 参考になる)

      by Anonymous Coward on 2003年08月07日 0時44分 (#373686)
      これらは同じファイル名です。
      Byte列が違えば文字列やファイル名も異なるなんていう幻想は捨てなさい。
      大文字小文字が区別されるとの思い込みもここから来る誤った前提です。全
      てはファイルシステム次第で変ります。
      まずは以下を読んで基礎知識を得ることを勧めます。さらにUnicodeと
      normalizationについても勉強が必要です。
      Text Encodings in VFS
      http://developer.apple.com/qa/qa2001/qa1173.html
      HFS Plus Volume Format
      http://devworld.apple.com/technotes/tn/tn1150.html
      親コメント
    • by Anonymous Coward
      いや、大問題だと思う。
  • 個人的には案外困ってないし、これまで十数年も case insensitive でやってきたんだから実用上の問題もさほどないんじゃないかと思います。
    気分の問題以外にこの変更を積極的に支持する理由ってなんかありますか?
    # 反対はしないけど、いまさらって感じが。
    • PerlのHTTP関連をあつかうライブラリlibwww [cpan.org]をインストールしたとき、一緒にHTTP HEADメソッドを実行するコマンドHEADを/usr/binにインストールされてしまい、酷い目にあいました。

      /usr/bin/head が上書きされましたもんで、そりゃもう。
      親コメント
      • その場合、いくらファイルシステムが識別してくれるからって
        かち合わないように大文字にすればいいやっていう魂胆がどうかしてると思う。>libwww

        head, HEAD, Head, hEAD, HEad...

        どれがどんな意味を持ってるか単語じゃなくて大小で区別しろってことでしょ。
        • うーん、それを言いだしたら
          • /usr/bin/CC

          • /usr/bin/cc


          • とか幾つかありますよね。(Mac OS Xには有りませんが)

            UNIXライクなOSにおいて大文字小文字を区別するファイルシステムを前提にして良いのが文化か、はたまた単なる通説なのかは知りません。この辺を述べた文書ってどこかにあるのでしょうかね?
          親コメント
  • by Anonymous Coward on 2003年08月08日 9時38分 (#374801)
    nkfは古川さんのところ [tcp-ip.or.jp]にあるものが最新版なので要注意。SourceForge.JPのプロジェクトページ [osdn.jp]もチェックした方がいいと思う。
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...