Linuxはマッピングフォルダ->ファイル名-> iノードをどのように保存しますか？
Linuxファイルシステムについて少し読み始めました。いくつかの場所で私はこのような引用を見つけました：
Unixディレクトリは、関連付け構造のリストであり、各ディレクトリには1つのファイル名と1つのiノード番号が含まれています。
そのため、各ディレクトリにはその下のファイルの名前が含まれ、各ファイルはiノードにマップされることがわかりました。しかし、私がするとき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
各ファイル名の横にiノード番号が表示されると思っていましたが、なぜそうではないのですか？
ディレクトリは、意味的に言えば、ファイル名からiノードへのマッピングです。これは、アプリケーションとファイルシステム間のインターフェイスに対応する、ディレクトリツリーの抽象化の設計方法です。アプリケーションはファイルを名前で指定し、ディレクトリ内のファイルのリストを列挙できます。各ファイルには、「iノード」と呼ばれる一意の指定子があります。
このセマンティクスがどのように実装されるかは、ファイルシステムのタイプによって異なります。ディレクトリがどのようにエンコードされるかは、各ファイルシステム次第です。ほとんどのUnixファイルシステムでは、ディレクトリはファイル名からiノード番号へのマッピングであり、iノード番号をiノードデータにマッピングする別のテーブルがあります。 （iノードデータには、アクセス許可やタイムスタンプ、ファイルの内容の場所などのファイルメタデータが含まれます。）マッピングには、リスト、ハッシュテーブル、ツリーなどがあります。
このマッピングはVimでは見ることができません。 Vimはディレクトリを表すストレージエリアを表示しません。 Linuxは、他の多くの最新のUnixシステムと同様に、アプリケーションがディレクトリ表現を直接見ることを許可していません。ディレクトリは、ディレクトリエントリとメタデータに関しては通常のファイルのように機能しますが、コンテンツに関してはそうではありません。 open、read、write、closeなどのシステムコールを使用して通常のファイルから読み取られるアプリケーション。ディレクトリの場合、他のシステムコールがあります：opendir、readdir、closedir、およびディレクトリの変更は、ファイルを作成、移動、および削除することによって行われます。 catのようなアプリケーションは、open、read、closeを使用してファイルのコンテンツを読み取ります。 lsのようなアプリケーションは、opendir、readdir、closedirを使用してディレクトリのコンテンツを読み取ります。 Vimは通常catのように機能してファイルのコンテンツを読み取りますが、ディレクトリを開くように要求すると、lsのように機能し、データを適切にフォーマットされた方法で出力します。
内部でディレクトリがどのように見えるかを確認したい場合は、ext2/ext3/ext4用のdebugfsなどのツールを使用できます。何も変更しないでください！ 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
/にディレクトリエントリの名前が表示されますが、他の文字の中には印刷できないものもあります。それを理解するには、ファイルシステム形式の詳細を知る必要があります。
その引用は、（論理的には、実際の構造は最近では非常に異なることが多い）Unixファイルシステムがどのように機能するかについてです。また、たとえば-iフラグをlsにすると、iノード番号を確認できます。
$ 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
左側のその番号はiノードです。そして、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
アクセス許可とサイズは、ディレクトリではなく、iノードの一部です。 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
bとcは、同じiノードを共有しているため変更されました。
ただし、カーネルは、明確に定義されたAPIを介してファイルシステムをユーザースペースにのみ公開します（/dev/sda1などのrawデバイスを除く）。リンクの作成と削除、権限の変更、ファイルの読み取りと書き込み、名前の変更などを行うための一連のシステムコールへのアクセスをユーザースペースに提供します。基になる生のファイルシステムデータ構造をユーザースペースに公開しません。これには多くの理由があります。ネットワークファイルシステムを許可します。つまり、カーネルがアクセス許可を適用し、ファイルシステムのデータ構造を正しく維持できることを意味します。つまり、ユーザースペースを変更せずに（異なるデータ構造を持つ）異なるファイルシステムを使用できます。
したがって、基本的に、vim dirはディレクトリリストを表示しているだけです。多かれ少なかれlsと同じです。それはトップにあるように、Netrwと呼ばれるvimモジュールを介して行われます（vimで:help netrwを試してください）。基盤となるファイルシステムのデータ構造を実際に編集することはできません。
Unixファイルシステムがどのように機能するかについての本当に、本当に古い説明を読んでいるのではないかと思います。あなたが説明することは、1970年代後半かそこらで真実でしたが、現代のファイルシステムではもはや真実ではありません。
最近の多くのプラットフォームでは、一般的に使用されているファイルシステムがいくつかあり、それぞれが内部をユーザースペースから隠しています。それらがどのように見えるかを見つけて遊んでみることができますが、ファイルシステムの設計を専門にしたい場合を除いて、本の著者を信頼して、設計の基本を理解するのに十分な知識を与えてください。詳細が多すぎます（いずれにせよ、必要になるまでに廃止されるものもあります）。