大文字小文字を区別するファイルシステムと区別しないファイルシステム、どっちがいい? 204
ストーリー by headless
区別 部門より
区別 部門より
Linux の NTFS3 ドライバーで大文字と小文字を区別しないマウントオプション「nocase」追加が提案され、Phoronix のフォーラムでは大文字と小文字を区別するファイルシステムの是非について議論が盛り上がっている
(Phoronix の記事)。
Windows も「まともな」OS のように大文字小文字を区別すべきだといった意見や、大文字と小文字を区別しないファイルシステム上のファイルを Linux のツールで操作したらどうなるのか心配する意見も見られるが、Linux のネイティブファイルシステムでも ext4 や f2fs が大文字小文字を区別しない機能をサポートしている。逆に Windows 10 バージョン 1803 以降では NTFS にディレクトリ単位でファイル名の大文字と小文字を区別するフラグが追加されており、fsutil コマンドを使用して有効化が可能だ。
人間は大文字と小文字の違いだけであれば同じ名前だと認識するため、平均的なユーザーには大文字と小文字を区別するファイルシステムを理解しにくい、実用的に大文字と小文字の組み合わせのみが異なる同名のファイルを同じフォルダーに格納できることが役に立つ場面は少ない、といった意見も見られる。スラドの皆さんはどう思われるだろうか。
Windows も「まともな」OS のように大文字小文字を区別すべきだといった意見や、大文字と小文字を区別しないファイルシステム上のファイルを Linux のツールで操作したらどうなるのか心配する意見も見られるが、Linux のネイティブファイルシステムでも ext4 や f2fs が大文字小文字を区別しない機能をサポートしている。逆に Windows 10 バージョン 1803 以降では NTFS にディレクトリ単位でファイル名の大文字と小文字を区別するフラグが追加されており、fsutil コマンドを使用して有効化が可能だ。
人間は大文字と小文字の違いだけであれば同じ名前だと認識するため、平均的なユーザーには大文字と小文字を区別するファイルシステムを理解しにくい、実用的に大文字と小文字の組み合わせのみが異なる同名のファイルを同じフォルダーに格納できることが役に立つ場面は少ない、といった意見も見られる。スラドの皆さんはどう思われるだろうか。
今更、区別する→しないは有り得ないのでは (スコア:2, 興味深い)
区別してたのをしなくしたら、区別する前提でのtar.gzファイルを展開した時とか、
ファイル群をコピー・移動したりすると衝突しておかしくなっちゃうじゃないですか。
Re: 今更、区別する→しないは有り得ないのでは (スコア:2, 参考になる)
*nixルータのファームウェアをWindowsで展開しようとしたときに衝突して面倒だったな
Re:今更、区別する→しないは有り得ないのでは (スコア:2, おもしろおかしい)
若かりし頃データベースのテーブル作るときに全部小文字でタイプして作業したとき、アプリケーションがWindowsでは動くのにLinuxでは動かないという現象に遭遇して調べたらSQLが全部大文字だったのでLinuxではテーブルが見つからない扱いだった。
Re: (スコア:0)
LinuxとWindowsの両方でクロス開発とか珍しくないしUNIX系のMAC OSすらも区別しないし
そもそも同一階層に大文字小文字区別前提でファイルを作るとか普通の感覚だと避けるでしょ。
人間には大文字小文字をいちいち区別するのはメンドクサイから。
Re: Re:今更、区別する→しないは有り得ないのでは (スコア:2, 興味深い)
時には他人の作ったファイルを同一階層に取り込むこともあるし、プログラムが自動でファイルを吐き出すこともある
って考えると「普通の感覚」をアテにしちゃあマズいんじゃないですかね
Re: (スコア:0)
MacやWindowsとクロス開発しないで大文字小文字区別する設定のままやってれば問題ないよ。
クロスした時点で破綻するからそんな案件には近寄りたくないけどな。
Re: (スコア:0)
今はAndroidとかで素人でも大文字小文字区別環境に触れることは多く、Windowsと同じつもりでファイル名の大文字小文字を変更して保存したら別ファイルになって知らぬ間に容量を圧迫されるなどの被害を被る可能性がある
混乱を来たす大文字小文字同一視ファイルシステムは滅ぼし尽くされるべき
素人はコマンドラインや設定ファイルなどで読み込むファイル名を手入力で指定することなんてそう多くないから、大文字小文字が違っていてファイルが読み込まれずに戸惑う心配なんて要らない
Re:今更、区別する→しないは有り得ないのでは (スコア:1)
Androidって大文字小文字区別するんだ。
素人じゃないけど知らなかったぞ。
Re:今更、区別する→しないは有り得ないのでは (スコア:4, 興味深い)
OSから見る時のファイル名は文字列型なので常に区別されます。ファイルシステムに書き込む時に正規化されたりされなかったり、読み出す時に区別されたりされなかったりします。「デベハトップ」に正規化されることもあるでしょう。
なのでフルパスを指定してファイルを書き込んでそのファイルを読み込んだ時のファイルオブジェクトの持っているフルパスが先のものと一致(?)するかどうかは時と場合と運により、OS名では一概に言えないはずです。Linux KernelでもFAT16とかから起動してたら区別されないんではないでしょうか。
Re:今更、区別する→しないは有り得ないのでは (スコア:1)
そもそもWindows/FAT/NTFSだって大文字小文字の正規化はしないよね。
ショートファイルネーム部分は正規化されるけど、もはやショートファイルネームはオプションと思った方が良いくらいの代物だし。
区別してるけど重複を許可せず大文字小文字無視でマッチしてると言う感じ。
Re: Re:今更、区別する→しないは有り得ないのでは (スコア:1)
SDカードスロットがあると大容量版が売れないからでしょ
Re: Re:今更、区別する→しないは有り得ないのでは (スコア:1)
旧MacOSで区別してなかったから、MacOSXでも基本的には区別してない。
システム的には大文字小文字の区別には対応してる。
Re:区別しない→するだってあり得ない (スコア:2, すばらしい洞察)
なんか問題の根の深さがあまりわかっていないようなので、ほんの一例を上げると
と
が統一されていないソースコードが世界中の至るところにある。バイナリに埋め込まれているファイル名だって星の数ほどある。
英語圏ではそれで済むのか (スコア:2)
他の言語は知らないが、日本語だと「ぁぃぅぇぉ」とか、空白文字にも全角とかある。
これらがすべて大文字、もしくは半角と全角の空白文字が同一視されるなら、英語圏の大文字ファイルシステムでも構わない。
日本人なら、(というか多言語を処理するなら) すべて大文字という文化に違和感を感じるんじゃないか?
初心者が作ったコードを添削するとき、無駄になる時間が少なくないんだよな。
X68000が通った道 (スコア:1)
X68000のOS、Human68kは、MS-DOS互換的に、ファイルシステムとしてFATを採用してたんですが、
DOSの8+3形式を独自に拡張して 小文字を利用可能としてさらに18+3のファイル名表現ができるようになっていました。
ところが、ファイル名の識別としてはDOSと同じ8+3だけで、
9文字目~18文字目だけが異なるものは同じファイル扱いで、大文字小文字も区別なし。
一件便利そうに見えて、GNUなどUNIX系のファイルを持ってきた時の不便さというか罠っぷりから、
「ファイル名の識別を18+3にする」という常駐プログラム「TwentyOne.x」が登場、
その便利さから「X68000にとって必須のソフト」扱いレベルで流行ります。
オプション指定で「大文字小文字も区別する」こともできましたが
逆に既存の大文字小文字を区別してないプログラムで問題が起こることがあるという癖の強いものでした。だからデフォルトでは区別なし。
ってことで、X68000でのカオスっぷりを体験した身からすると、現行のシステムで大文字小文字の区別有無を変更するってのは茨の道としか思えないです…
セキュリティ的には (スコア:0)
セキュリティ的には大文字小文字を区別しないと不利なんじゃなかったっけ? 理由はわからん。 何かで見た。
最初から小文字だけとか大文字だけしか受け付けないとかいう設計にすればよかったんじゃね? そうすればデジタル化!で、英語でも大文字か小文字が廃止されていたかもしれん。 FAXは古い、的ノリで。
Re:セキュリティ的には (スコア:1)
インジェクションでcmd.exeを置き換えてcmd.exe の自動実行をすげ替えるとき、区別だと呼び出し cmd.exe に対して CmD.eXE とかは反応しないけど、Windowsだとしちゃうね。んでインジェクション検知の正規表現マッチングで grep -i みたいにしないといけないし、Perlなら[A-Z][a-z] しないといけない。パターンがザルだとくぐり抜けられちゃう。多分そういうことだと思う
Re:セキュリティ的には (スコア:2, 参考になる)
そういう脆弱性は良くありますね。
特に、Unix向けに開発されたソフトウェアをWindowsに移植した場合にね。
CWE-178: Improper Handling of Case Sensitivity
https://cwe.mitre.org/data/definitions/178.html [mitre.org]
Re: (スコア:0)
物理ファイルにアクセスできる可能性が増えるからじゃね。
AAAAAAAA.EXEとaaaaaaaa.exeが区別されないなら、1tryで2patternのattackしたのと等価になる。
>最初から小文字だけとか大文字だけしか受け付けないとかいう設計にすればよかったんじゃね?
MS-DOSは小文字を受け付けませんでした。小文字で指定してもファイルは大文字で作成される。
Re:セキュリティ的には (スコア:1)
仕事を持って帰って、家のX68kで作業してうっかり小文字で保存したまま会社に持って行って、
ファイルにアクセスできなかった時はどうしようかと思いました。
幸いにもFDで「名前の変更」→即確定で大文字に出来たので事なきを得ましたが。
FILMTNでは駄目でした。
Re: (スコア:0)
>MS-DOSは小文字を受け付けませんでした。小文字で指定してもファイルは大文字で作成される。 なんとなく、システムファイルは小文字、ユーザーファイルは大文字にすれば、面白いと思った。そうすれば、ユーザーがシステム予約で作
Re: Re:セキュリティ的には (スコア:1)
Re: (スコア:0)
コンピュータ側はIDだろうと何でもいいけど人間が番号だけで理解できるとは思えないのですが?
Re: (スコア:0)
別に番号だけを使う必要はない。 ファイルを一意に特定するのに、ファイル名を使う必要はない、と思っているだけ。 人間向けには名前を別に付ければいい。でも、それをIDとしては使わない。
Re: (スコア:0)
MS-DOS時代のPC-98向けOASYS互換ワープロがそんな作りだった。
ファイル名に不自由しない現代では意味があるとは思えない。
Re: Re: Re:セキュリティ的には (スコア:2)
ファイル名はなんか256バイトくらいの手打ち文字列なので、そんなもんをキーにするのはおかしいという発想には同意できるものもないでしょうか。はしご高とかファイル名がエスケープシーケンスみたいなエッジケースもありますし。
ローマ人 (スコア:0)
小文字とかいうややこしいものを発明した奴、出てこい!
Re: (スコア:0)
アクセント記号もいらないですね。AとAEは同一視すべきです。
Re: Re:ローマ人 (スコア:1)
Re:ローマ人 (スコア:1)
そして象形文字に戻る
では平仮名と片仮名では? (スコア:0)
漢字だっていろいろ字体があるし、ラテン文字だってそうだろう。 中途半端はすべきではないから、全部別が良い。
Re: (スコア:0)
全角と半角もね。
ローカライズ関連の機能を変に使ってしまった結果、1.txt(「1」は全角)と一.txtの区別ができないアプリ、とか見たことがある。
Re: (スコア:0)
漢字だっていろいろ字体があるし、ラテン文字だってそうだろう。 中途半端はすべきではないから、全部別が良い。
わたなべ「そのとおり」
さいとう「そのとおり」
Anonymous Coward「いやべつに」
Re:では平仮名と片仮名では? (スコア:2, すばらしい洞察)
人名専用の異体漢字は廃止すべきだったよね。
馬鹿馬鹿しい事この上ない。
Re:では平仮名と片仮名では? (スコア:1)
>「戸籍に登録されてるものが正」とかいう考えが誤りだと思う
日本人の氏名は図形です。戸籍に書かれている図形が正式な氏名です。文字ではないのです。
Re:では平仮名と片仮名では? (スコア:2)
そういや、メジャーなファイルシステムでは「パ」と、「パ」は区別されるんだろうか。
Explorerのみかと (スコア:0)
Explorerは区別しないがNTFSは区別しているのかと思っていた。
Re: (スコア:0)
区別しているけど、大小の重複は許さないファイルシステム運用だと思ってた。
全部uuidで識別して (スコア:0)
表示名とかフォルダ階層とかはアプリケーション層の情報にしろ
Re: (スコア:0)
超漢字
ls でファイルを把握していると、 (スコア:0)
ls でファイルを把握していると、先頭 大文字は先・左に、小文字は後・右にと 離れてリスティングされるのでまったく気にせずにファイル作ってるなぁ。 ただ調べてみたら大文字小文字違いで同じファイル名は自分では ほぼ作ってなかった。
むしろシステム側(FreeBSD 10.2R)の方に散見される感じ。 /usr/bin/ に CC と cc、Mail と mail とか、 /usr/local/include/X11/bitmaps に stipple と Stipple とか、 /usr/local/lib/perl5/5.20/ に Perl/ と perl/ とか、 /usr/local/share/xpaint/include/ に Xpaint.h と xpaint.h とか。 man page はどちらでも引けるように両方用意してあるとか。(scsi とか)
名前考えるのが面倒くさいときに 大文字が dir で小文字がその config とかやりそう。
Re: (スコア:0)
lsがだめならslをつかえばいいじゃない
# ぽっぽー
Re:ls でファイルを把握していると、 (スコア:1)
# SLIP
Re:fsutil コマンドを使用して有効化が可能だ (スコア:0)
MSの公式ドキュメントにリンクしろよ無能が
Modify case sensitivity [microsoft.com]
Re:「まともな」OSって言うけど (スコア:1)
OS自体はサポートしてるんだけどね。OSのインストーラーが歴史的な経緯で区別しない設定でフォーマットしてる。
たまに大文字小文字混在してるソース出くわすけど、コンパイル時に必要なだけなら幸いOSの標準機能だけで解決できるよ。
ディスクユーティリティー使えば好きなフォーマットで空のディスクイメージ作れるから、区別する設定で適当なイメージファイル作ってそれをマウントする。あとはディスク内部をただの一時フォルダーのように使ってコンパイルして、バイナリだけ外にコピーすればいい。
Re:「まともな」OSって言うけど (スコア:1)
最初は強制正規化をやめてたけどさすがに無茶だったのかAPFSになってからも何度か仕様が変わってる
Re:とりあえず (スコア:1)
そうやってルールを複雑化していけばきっとトラブルが増えるから心配するな
Re: Re:とりあえず (スコア:1)
そうだよ。空白の入ったファイル名を正しく扱えないアプリをあぶり出すためにあえてああしたと公式に言っている
Re:Mac (スコア:2)
Re:Mac (スコア:1)
Linuxに至るまで残ってるというのはある種ノスタルジアですなあ