「ハードリンク」は、単に同じ基本データ構造を参照するファイルシステム階層内の2つ以上の項目の場合です。あなたの写真はこれを完全に示しています！

ここにあるすべてがそれです。まるで「パン：3ページ参照」と「ベーカリー：3ページ参照」というインデックスが最後にある料理本と同じです。 3ページのコンテンツには2つの名前があります。

同じページを指すインデックスエントリを必要なだけ持つことができます。何ですかいいえうまくいくのは、他の本の内容のインデックスエントリがあるということです。他の本はまったくありません。存在する現在、書籍ではページの引用は機能しません。特に、他の本の異なるバージョンは、時間の経過とともに異なる番号が付けられた可能性があるためです。

単一のファイルシステムは独自の一貫性のみを保証できるため、常に破損しない限り、他のファイルシステムのinodeなどの「プライマリストレージシステムの詳細」を参照することはできません。したがって、別のファイルシステムに格納されているディレクトリエントリを参照するには、パスを介して参照する必要があります。 UNIXはシンボリックリンクを介してこれを達成するのに役立ちます。

私が見た唯一の問題は、複数のファイルシステムが同じ範囲のinodeを持つことができるということです（しかし、オペレーティングシステムではinodeが制限されているので、そうは思いません）。

これは事実でも論理でもありません。私のハードドライブを送ることができます。そうですね。ハードドライブのファイルシステムに、コンピュータ上の多くのファイルシステムの1つですでに使用されているinode番号がないことを確認するにはどうすればよいですか？

また、inode自体にファイルシステムに関する新しい情報を追加するのはなぜ良いのでしょうか？本当に便利ではないでしょうか？

いいえ。ファイルシステムを「ストレージメディアのバイト」の抽象化と考えてください。ファイルシステム自体は独立ファイルで構成されるデータを含むデータ構造で、完成のために外部データに依存することはできません。これに違反すると、不一致だけが発生します。独立性は、ファイルシステムBについて知らなくてもファイルシステムAのinode番号を変更できることを意味するからです。 BがAに依存すると、Bは破壊されます。

この質問の問題は、それが嘘に基づいているということです。そんなことはどんな状況でも不可能だという考えに基づいている。これがどのように機能するのか想像しやすいので、これが不可能な理由を説明しようとしても役に立ちません。

克服すべき２つの問題がある。これらの問題は、オペレーティングシステムの開発者が実装を試みることを妨げるのに十分です。

最初は引用方法です。どのハードリンクは他のファイルシステムを指します。

実行中のオペレーティングシステム内でマウントされた各ファイルシステムに一意の番号を割り当てることができます。これにより、オペレーティングシステムは、どのマウントされたファイルシステムがどのinodeを担当しているかを知ることができます。ただし、この番号はインストール中にのみ有効です。オペレーティングシステムを再起動するか、ファイルシステムをアンマウント（移動、プラグ解除など）すると、この番号が変更されることがあります。

ファイルシステムのUUIDを使用できますが、信頼性が疑わしいとしましょう。複製と移行により、ファイルシステムに重複したUUIDが存在する可能性があります。

これは不可能ではありませんが、そうすることで、異なるファイルシステムのファイルシステムドライバ間でデザインが過度に結合する可能性があるため、多くの開発者はそうしないことをお勧めします。

2番目の問題は、ファイルシステム自体がファイルに存在するリンクの数を知る必要があることです。ファイルシステムは、リンクが残っていない場合にのみファイルを削除します。参照カウントが正しいことを確認するにはファイルシステムチェックが必要であるため、外部参照カウントをインバウンドに保存する必要があります。ただし、数を維持するために、両方のファイルシステムが常に一緒にマウントされるという保証はありません。

他のファイルシステムがハードリンクを保持しているため、ファイルシステムがこれらの参照を保存してファイルを削除するのではなくファイルを保持している場合、他のファイルシステムが消去または破損した場合はどうなりますか？

外部ファイルシステムにアクセスせずに削除するには、管理タスクを実行する必要があります。これは実際に非常に危険なツールです。

一般に、ファイルシステムの検査は外部リンクを監査して変更することが困難であり、他のファイルシステムの代わりに１つのファイルシステムをマウントすることによって生じる不整合が一般的である。

ハードリンクとは何ですか

inodeとinode参照を混同しています。ハードリンクは inode 参照です。

ハードリンクは存在せず、そのようなものもありません。少なくともシンボリックリンクはありません。ファイルごとに少なくとも1つあります。これはファイル参照にすぎません。

他のファイルシステムへのハードリンクを持つことはできますか？

いいえ

@MarcksMüllerが言ったように、ページ番号は本のページを表します。

はい

しかし、それは同じではありません：それはハードリンクではありません。

シンボリックリンクを使用できます。または、UUID / inode番号またはUUID /ファイルパスを使用して、関連付けられた新しいファイル形式を実装することもできます。これがすでに存在しているかどうかはわかりませんが、まだ見たことがありません（NTFSにあると思います）。

質問に関する注意事項

図が正しいようです。

ただし、インデックスノードが一意である必要があるというあなたの主張は間違っています。 USB接続デバイスをあるコンピュータから別のコンピュータに移動すると想像してください。それはうまくいきますが、おそらく既存のデバイスと同じinode番号を使用します。

私はあなたの質問に答えようとしていません。しかし...

ディレクトリ内のすべてのエントリはシンボリックリンクを含む「ハードリンク」です。

それは間違っています。

実際、最初の部分は正しいです。ディレクトリの各エントリはハードリンクです。しかし、シンボリックリンクはいいえディレクトリのエントリです。シンボリックリンクは文書、inodeのフラグは、オペレーティングシステムがプログラムがシンボリックリンクにアクセスしようとしたときにオペレーティングシステムがアクセスを特別に処理する必要があることを除いて、他のファイルと同じです。 *

作者はおそらくこれを知っていましたが、シンボリックリンクではなくハードリンクを説明するのに怠っていました。彼らがそんなに怠惰でなかったら、こう言うことができたでしょう。

ディレクトリの各エントリはハードリンクです。均等な立場~のためシンボリックリンク（シンボルリンクは実際に特別な種類のファイルです）は「ハードリンク」です。到着シンボリックリンクファイル。

*特殊処理**は、プログラムがシンボリックリンクにアクセスしようとしたときに提供されます。

1. シンボリックリンクファイルを開き、
2. シンボリックリンクファイルからパス名を読み込みます。
3. シンボリックリンクファイルを閉じて、
4. 入場ターゲットファイル（つまり、シンボリックリンクファイルから読み取られたパス名で名前が付けられたファイル）まるでこれは、プログラムが初めて開くように要求するファイルです。

ターゲットファイルが別のシンボリックリンクである場合は、非記号リンクファイルが見つかるまで、または次のファイルが表示されるまでプロセスが繰り返されます。ELOOPエラーコード返されます。

**シンボリックリンクに「従わない」システムコール内には、いくつかのシステムコールおよび/またはオプションがあります。そうしないと、lsプログラム（たとえば）がシンボリックリンクに関する情報を提供したり、シンボリックリンクを作成または破壊したりする可能性があるため、これが必要です。