私はLinuxファイルシステムについて少し読み始めました。私はこの引用をいくつかの場所で見つけました。
Unixディレクトリは一連の連想構造で、各構造にはファイル名とinode番号が含まれています。
だから私は各ディレクトリにその下にあるファイル名が含まれていて、各ファイルがinodeにマップされていることを知りたいと思います。ただしvim directory_name、Ubuntuでこれを行うと、次の結果が表示されます。
" ============================================================================
" 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ファイルシステムがどのように機能するかについてです（論理的に言えば、現在の実際の構造はしばしば非常に異なります）。次の-iフラグを使用してinode番号を表示できます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
左側の数字はインデックスノードです。実行すると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
/dev/sda1ただし、カーネルは明確に定義されたAPIを介してのみファイルシステムをユーザースペース（RAWデバイス以外）に公開します。リンクの作成と削除、権限の変更、ファイルの読み取りと書き込み、名前の変更などの操作を実行するために、複数のシステムコールへのユーザー空間アクセスを許可します。元の基本ファイルシステムデータ構造をユーザー空間に公開しません。これにはいくつかの理由があります。つまり、ネットワーク化されたファイルシステムを許可します。これは、カーネルが権限を適用し、ファイルシステムのデータ構造を正しく維持できることを意味します。これは、ユーザースペースを変更することなく他のファイルシステム（他のデータ構造を含む）を使用できることを意味します。
したがって、デフォルトではvim dirディレクトリのリストが表示されます。おおよそ次のようになりますls。 Netrwと呼ばれるvimモジュールを介して実行されます。このモジュールは上記のものと正確に一致します（:help netrwvimで試してください）。デフォルトのファイルシステムデータ構造は実際には編集できません。
答え2
意味上、ディレクトリはファイル名から inode へのマッピングです。これは、アプリケーションとファイルシステム間のインタフェースに対応するディレクトリツリー抽象化が設計される方法です。アプリケーションは、名前でファイルを指定し、それぞれ「inode」という一意の識別子を使用して、ディレクトリ内のファイルのリストを列挙できます。
このセマンティクスの実装方法は、ファイルシステムの種類によって異なります。ディレクトリのエンコード方法は、各ファイルシステムによって異なります。ほとんどのUnixファイルシステムでは、ディレクトリはファイル名からinode番号へのマッピングであり、inode番号からinodeデータにマッピングされる別々のテーブルがあります。 （inodeデータには、権限、タイムスタンプ、ファイルの内容の場所などのファイルメタデータが含まれています。）マップは、リスト、ハッシュテーブル、ツリーなどです。
Vimを使用してこのマッピングを表示することはできません。 Vim は、ディレクトリを表す記憶域を表示しません。他の多くの最新のUnixシステムと同様に、Linuxではアプリケーションがディレクトリ表現を直接見ることはできません。ディレクトリエントリとメタデータでは、ディレクトリは通常のファイルのように動作しますが、内容ではそうではありません。open、、readなどwriteのシステムコールを介して通常のファイルから読み取るアプリケーションcloseです。ディレクトリの場合、別のシステムコールがあります。opendir、、、ディレクトリの変更は、ファイルreaddirのclosedir作成、移動、削除によって行われます。このようなアプリケーションは、、をcat使用してファイルの内容を読み込みます。このようなアプリケーションは、、を使用してディレクトリの内容を読み込みます。 Vimは通常ファイルの内容を読み取るように動作しますが、ディレクトリを開くように要求するとVimはそのように動作し、正しい形式でデータを印刷します。openreadcloselsopendirreaddirclosedircatls
ディレクトリの内部構造を表示するには、debugfsext2/ext3/ext4 などのツールを使用できます。何も修正していないことを確認してください！このようなツールはdebugfsファイルシステムを迂回して完全に破損する可能性があります。 ext2/ext3/ext4debugfsは、コマンドラインオプションで明示的に書き込みを許可しない限り、読み取り専用モードなので安全です。
# 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年代後半には本当でしたが、現代のファイルシステムではもはや真実ではありません。
多くの最新プラットフォームには、一般的に使用されている複数のファイルシステムがあり、各ファイルシステムはユーザー空間内の内部構造を隠します。どのように見えるか見て使用することができますが、特にファイルシステムを設計したくない場合は、この本の著者があまり詳しく説明せずにデザインの基本的な理解を提供することを信頼するのが最善です（とにかく、これらの詳細は再び必要なとき最新情報ではありません。）