指定された順序で次のコマンドを実行しました。
$ln a b
$ls -i a b
523669 a 523669 b
$rm -f a
$ls -i b
523669 b
私はこのテストでコマンドがrm実際にファイル名（aこのテストでは）だけを削除し、ファイルは削除しないと結論付けました。なぜなら、inodeがまだ存在し、他のファイル名（b）で検索できるからです。
私の質問は、ファイルがファイル名にのみハードリンクされている場合、そのファイルrmで実行されたときに実際のファイル（つまりinode）が完全に削除されるのですか？そうでない場合は、ファイル名なしでinodeだけでファイルinodeを検索できますか？
答え1
inodeを介してファイルを開こうとすると、すべてのディレクトリナビゲーションがバイパスされます。ファイルの権限とファイルを指すディレクトリを決定するには、ディレクトリの巡回が必要です。ディレクトリナビゲーションがないと、カーネルは呼び出しプロセスがファイルにアクセスできるかどうかを判断できません。
一つあるファイル記述子からファイルリンクを生成できるように、Linuxカーネルにパッチを適用することをお勧めします。。それこれを安全に実装することは非常に難しいので拒否されました。。
Linuxでは（おそらく同じ理由で他のUNIXバリアントでも）削除されたファイルへのリンクを作成できないため、ファイルに名前がない場合は名前を再追加できません。 1削除したファイルを開いて開くことができます/proc/$pid/fd/。
ファイルにリンクがなくなり、開かれていない場合、そのファイルは存在しなくなり、以前にそのデータが使用していたスペースをいつでも回収できます。
1 ext2 / ext3 / ext4を使用して、ファイルシステムに応じてファイルシステムのバイトを直接調整します。debugfsこれには、ファイルシステムがマウントされたデバイスへのアクセスが必要です（つまり、通常はルートのみを試すことができます）。ただし、debugfsはinodeを介してファイルにアクセスできますが、ファイルが削除されても役に立ちません。アプリケーションがファイルを閉じると、ファイルは実際に削除され、マウントされたファイルシステムで読み取り/書き込みモードでdebugfsを実行するのはレシピ災害です。
答え2
「ln」および「rm」コマンドは、1970年代初頭以降、すべてのUNIXファイルシステムでまったく同じように動作しました。 Mac OSX、BSD、Linuxはすべてこの独創的なデザインを継承しました。
UNIXファイル自体には名前がなく、ただインデックスノード数値または整数。ただし、名前を関連するinumに関連付ける特別な「カタログ」ファイルのエントリからのみアクセスできます。 inum を直接指定することはできません。
ディレクトリはそれ自体ファイルなのでアクセスも必要です。それ（他の）ディレクトリなどを介してスラッシュ（/）で区切られた一連のディレクトリ名（「パス名」と呼ばれる）を介して。パスは、名前が「/」で始まらない限り、プロセスの「現在の作業ディレクトリ」から始まります。この場合、パスはファイルシステムのルートから始まります。たとえば、パス名に "/"文字が含まれていない場合は、現在のディレクトリのエントリでなければなりません。
ディレクトリ以外のファイルは、「ハードリンク」と呼ばれるパス名をいくらでも持つことができ、みんなそのパス名が削除されました。そして最後のプロセスでファイルを閉じました。その後、ファイルは実際に削除され、そのスペースは再利用可能としてマークされます。つまり、単一リンクファイルをcreat（）またはopen（）してからunlink（）すると、そのファイルはファイルシステムの名前空間に表示されなくなりますが、ファイルは閉じるまで存在し続けます。これは、他のプログラムで読み取れない一時的なスクラッチファイルに役立ちます。
ディレクトリには inode 番号がありますが、ほとんどのファイルシステムでは、その番号が他のディレクトリ内にしか表示されないようにします。 （1つの珍しい例外は、Mac OSX HFS +ファイルシステムです。これにより、Time Machineバックアップが機能する可能性があります。）ディレクトリ（または他のファイル）への「ソフトリンク」の作成を続けることができます。ソフトリンクは、inumの代わりに別のパス名が含まれていることを除いて、ディレクトリエントリに似ています。
すべてのUNIXファイルには所有者、グループ、およびアクセス権があります。ファイルを開くために必要ですが、十分ではありません。また、ファイルを参照するために使用されるパス名のすべてのディレクトリに対して少なくとも実行権限が必要です。これがUNIXファイルをinode番号で開く標準的な方法がない理由です。これは、広く使用されている重要なセキュリティメカニズムを迂回します。
しかし、それはなぜ標準的な方法があり得ないのか説明しません。根（権限のある）ユーザーはとにかく権限確認をバイパスするので、inode番号でファイルを開きます。これは、バックアップなどの特定のシステム管理機能に役立ちます。私が知る限り、そのようなメカニズムは存在しますが、すべてファイルシステムによって異なります。すべてのUNIXファイルシステムに対する普遍的なアプローチはありません。
答え3
Linuxでは、debugfs、対話型ext2/ext3/ext4ファイルシステムデバッガは、lninode番号を取得し、filespecそのファイルへの新しいハードリンクを生成するコマンドを提供します。しかし実際には切断されたファイルはプロセスによって開いたままになります。、で開かれたファイル記述子を保持します/proc/[pid]/fd/[n]。削除されたファイルに対してこれを実行しようとすると、ファイルシステムが破損する可能性が高くなります。
これは、ext3（および拡張ext4）がクラッシュ後に切断から安全に回復できるようにするためです。inodeのブロックポインタを0にクリアします。ext2はブロックをブロックビットマップで未使用としてマークし、inodeを「削除済み」としてマークし、ブロックポインタを保持します。それにもかかわらず、ハードリンクを作成するにはファイルシステムを読み書きでマウントする必要があるため、削除されたファイル用に予約されたブロックが再割り当てされた可能性があります。
カーネルバージョン2.6.39以前ln -L|--logicalGNU coreutilsで導入されたオプションv8.0開いているファイル記述子を介して接続されていないファイルを回復するために使用できます。/proc/[pid]/fd/[n] もしリンクされていないファイルと新しいハードリンクの両方が次の場所にあります。一時ファイルシステムファイルシステムこの機能は以後障害のある、ので、ザイルズファイル記述子から直接ハードリンクを作成できるようにすることに関連するセキュリティ上の考慮事項があることを指摘してください。