Linux のファイル システムについて少し読み始めました。いくつかの場所で次のような引用を見つけました。
Unix ディレクトリは関連付け構造のリストであり、各ディレクトリには 1 つのファイル名と 1 つの inode 番号が含まれます。
そこで、各ディレクトリにはその下のファイル名が含まれ、各ファイルは inode にマップされているだろうと予想しました。しかし、vim directory_nameUbuntu で実行すると、次のような結果になります。
" ============================================================================
" Netrw Directory Listing (netrw v156)
" /Users/user/workspace/folder
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../
./
folder1/
folder2/
file1
file2
各ファイル名の横に inode 番号が表示されることを期待していましたが、なぜ表示されないのでしょうか?
答え1
この引用は、Unix ファイルシステムがどのように動作するか (論理的には、実際の構造は今日では非常に異なることが多い) に関するものです。たとえば、フラグを使用して inode 番号を確認でき-iますls。
$ ls -li
total 8
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 1 anthony anthony 70 Apr 25 12:07 b
左側の数字は inode です。そして、ln b c(ハードリンクを作成して) 実行すると、次のようになります。
$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 b
532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 c
権限とサイズはディレクトリではなく、inode の一部です。次の操作で簡単にわかりますchmod 0600 c。
$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 b
532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 c
両方とも同じ inode を共有しているため、変更されますb。c
ただし、カーネルは、明確に定義された API を介してのみファイルシステムをユーザー空間に公開します ( などの raw デバイスを除く/dev/sda1)。カーネルは、リンクの作成と削除、権限の変更、ファイルの読み取りと書き込み、名前の変更などを行うための一連のシステムコールへのユーザー空間アクセスを提供します。カーネルは、基盤となる raw ファイルシステムのデータ構造をユーザー空間に公開しません。これには、ネットワークファイルシステムが許可されること、カーネルが権限を適用してファイルシステムのデータ構造を正しい状態に保つことができること、ユーザー空間を変更せずに異なるファイルシステム (異なるデータ構造を持つ) を使用できることなど、多くの理由があります。
つまり、基本的には、vim dirとほぼ同じように、ディレクトリの一覧を表示するだけですls。これは、上記で説明されているように、Netrw と呼ばれる vim モジュールを介して実行されます ( :help netrwvim で試してください)。実際には、基礎となるファイルシステムのデータ構造を編集することはできません。
答え2
ディレクトリとは、意味的に言えば、ファイル名から inode へのマッピングです。これは、アプリケーションとファイルシステム間のインターフェイスに対応する、ディレクトリ ツリーの抽象化の設計方法です。アプリケーションは、ファイル名でファイルを指定して、ディレクトリ内のファイルのリストを列挙できます。各ファイルには、「inode」と呼ばれる一意の指定子があります。
このセマンティクスの実装方法は、ファイルシステムの種類によって異なります。ディレクトリのエンコード方法は、各ファイルシステムによって異なります。ほとんどの Unix ファイルシステムでは、ディレクトリはファイル名から inode 番号へのマッピングであり、inode 番号から inode データへのマッピングは別のテーブルで行われます (inode データには、権限やタイムスタンプ、ファイル内容の場所などのファイル メタデータが含まれます)。マッピングは、リスト、ハッシュ テーブル、ツリーなどになります。
Vim ではこのマッピングを見ることはできません。Vim はディレクトリを表すストレージ領域を表示しません。Linux は、他の多くの現代的な Unix システムと同様に、アプリケーションがディレクトリ表現を直接見ることを許可していません。ディレクトリは、ディレクトリ エントリとメタデータに関しては通常のファイルのように動作しますが、コンテンツに関しては動作が異なります。アプリケーションは、、、、などのシステム コールを使用して通常のファイルから読み取ります。openディレクトリのread場合は、他のシステム コールがあります: 、、、writeであり、ディレクトリの変更は、ファイルの作成、移動、および削除によって行われます。、、などのアプリケーションは、ファイルのコンテンツを読み取り、、、を使用します。Vimは通常、ファイルのコンテンツを読み取り、のように動作しますが、ディレクトリを開くように指示すると、のように動作し、データを適切な形式で出力します。closeopendirreaddirclosedircatopenreadcloselsopendirreaddirclosedircatls
ディレクトリの内部がどのようになっているかを確認したい場合は、debugfsext2/ext3/ext4 などのツールを使用できます。何も変更しないように注意してください。などのツールはdebugfsファイルシステムをバイパスし、ファイルシステムを完全に破壊する可能性があります。ext2/ext3/ext4はdebugfs、コマンドライン オプションで明示的に書き込みを許可しない限り、読み取り専用モードであるため安全です。
# debugfs /dev/root
debugfs 1.42.12 (29-Aug-2014)
debugfs: dump / /tmp/root.bin
debugfs: quit
# od -t x1 /tmp/root.bin
ディレクトリ エントリの名前が/、印刷できない文字を含むさまざまな文字の中に表示されます。これを理解するには、ファイル システム形式の詳細を知る必要があります。
答え3
あなたが読んでいるのは、Unix ファイル システムの動作に関する非常に古い解説書ではないかと思います。あなたが説明していることは 1970 年代後半頃までは真実だったのですが、現代のファイル システムではもはや真実ではありません。
最近の多くのプラットフォームでは、一般的に使用されているファイル システムが複数あり、それぞれの内部はユーザー スペースから隠されています。ファイル システムがどのように見えるかを調べて試してみることはできますが、ファイル システムの設計を専門にしたいのでなければ、あまり詳細に立ち入らずに、設計の基本を理解するのに十分な情報だけを本の著者が提供してくれると信頼する方がよいでしょう (詳細の一部は、いずれにしても、再び必要になったときには時代遅れになっているでしょう)。