私はこれについての私の理解が正しいことを確認したいと思います。
- ハードリンクを生成すると、同じ inode を指す別の dentry が生成されます。
- シンボリックリンクを作成すると、他のインデックスノードのディレクトリエントリを指すまったく新しいファイルオブジェクト/インデックスノードが作成されます。ファイルシステムは特別な方法でファイルを処理します（特定のタスクを別のinodeのdentryにリダイレクトします）。
ベストアンサー1
ハードリンクの場合は正確ですが、シンボリックリンクの場合は正しくありません。シンボリックリンクの内容は単なる文字列です。たとえば、これは現在マウントされていないファイルシステムを指すシンボリックリンクを許可します。シンボリックリンクは単なるテキストです。カーネルがシンボリックリンクに会ったら、デフォルトでシンボリックリンクを探しているパスに挿入し、スラッシュで区切られたフラグメントに分割し、必要に応じて検索し.ます..。シンボリックリンクは追加の権限を提供しません。シンボリックリンクのパス要素による巡回は、アプリケーションがこれらのパス要素を指定したのと同じ権限制約に従います。シンボリックリンクには独自のinodeがあります（または少なくともそのように見えます。後で、一部のファイルシステムはシンボリックリンクが複数のハードリンクを持ち、シンボリックリンクを含むディレクトリに直接保存することはできませんが、まだインデックスを報告します）ノード機能の数lstat）。
システムレベルでシンボリックリンクがどのように処理されるかは、ジョブの種類によって異なります。ディレクトリエントリの操作（名前の変更、削除など）は、シンボリックリンクを他のファイルと同じように処理します。ファイルの内容（たとえばopen）chdirに作用するアクションは、シンボリックリンクに沿ってターゲットに作用します。シンボリックリンクチェーンが壊れたリンクで終わると、エラーが報告されます。ファイルメタデータ（inodeなど）で動作する操作の場合は、次のように異なります。一部のタスクには一対の関数（例：stat/）がありlstat、他のタスクにはシンボリックリンクに従います（たとえば、Linuxchmodにはutimesシンボリックリンクバリアントはありません）。