ハードリンクを作成すると便利な場合

基本的に、ハードリンクには2つの主な制限があります。

1. 通常、ハードリンクでは、リンクとファイルが同じファイルシステムに存在する必要があります。
2. スーパーユーザーのみがディレクトリへのハードリンクを作成できます。

したがって、ハードリンクの制限を回避するためにシンボリックリンクが導入されました。質問は、ハードリンクはまだ必要ですか？それらがより役立つ状況があるのでしょうか？

ハードリンクは、ファイルシステムをより柔軟な方法で整理するのに役立ちます。基本的に、ハードリンクを使用すると、1つのファイルを取得して、ファイルシステム内の複数の場所に一度に配置できます。あなたが写真家であり、写真をたくさん持っているシナリオを考えてみてください（これは私の人生の例です！）。時々人々はあなたにそれらの写真を求めるので、それらに現れる人々によってそれらを整理するかもしれません。ただし、場所や日付ごとに整理することもできます。これらの3つをネストする実際の方法はありません。これらは完全に独立した組織の軸です。あなたは、これらの3つの異なるもののための3つの異なる階層を作成し、そして、すべての3つの中でそれぞれの写真の存在を持つことができるようにすることなく、各写真を3回保存する必要があります。それがハードリンクの魔法です。シンボリックリンクのリンクを解除します。「実際のファイル」がどこにあるのかを心配する必要はありません。それらはすべて実際のファイルだからです。ファイルは参照されなくなるまで保持され、最後のハードリンクを削除すると削除されるため、自由に削除および移動できます。シンプルであり、あまり追跡する必要はありません。

ファイルの内容は、すべてのハードリンク（はい、すべてのファイル名がハードリンクであり、最初のものも含む）が消去され、ファイルが閉じられるまでパージされません。そのため、複数の場所でファイルが必要な場合に役立ちますが、~/Downloads/coolsong.mp3との間など、いつでもそれらのファイルから削除できます~/Music/Cool Song.mp3。

シンボリックリンクに対するハードリンクのあまり重要ではない利点の1つは、ハードリンクのiノードに到達すると、カーネルがファイルにアクセスするためにそれ以上処理する必要がないことです。シンボリックリンクを検出すると、カーネルはリンク値を読み取り、ファイルのiノードに到達する前にディレクトリ構造を走査し続ける必要があります。これには時間がかかりますが、違いは必ずしも簡単に測定できるとは限りません。シンボリックリンク値の要素の1つがそれ自体がシンボリックリンクである場合、それは本当に楽しくなります。

ハードリンクにはいくつかの理由があります

1. 最後の参照がなくなるまでファイルへの参照を保持する（イグナシオが指摘したように）
2. ファイルをハードリンクすると、ファイルシステム内の1つのファイルのスペースしか占有しません（ファイルへの参照は両方とも同じiノードを共有します）。したがって、ハードリンクは同じファイルシステム上になければなりません。

したがって、ハードリンクを使用する理由の1つは、おそらく多くのスペースを節約することです...

いずれかの参照に追加すると、データが共有ファイルに追加されます。また、他のファイル記述子から読み取り中に1つのファイル記述子に追加することもできます（たとえば、tail -fを使用）

ここに示した例の多くは有効ですが、ソフトリンク（「複数の場所に1つのファイルが必要」などの問題）でも同様に機能します。

ハードリンクが本当に役立つ場合の良い例は、バックアップソフトウェアDirvishです。

Dirvishは、高速なディスクベースの回転ネットワークバックアップシステムです。

dirvishを使用すると、ファイルシステムの完全なイメージのセットを無人で作成および有効期限付きで維持できます。dirvishバックアップボールトは、データのタイムマシンのようなものです。

Dirvishは、ファイルを別の（バックアップ）ファイルシステム（USBハードディスクなど）にコピーすることにより、ファイルシステムレベルでバックアップを作成します（つまり、ファイルをコピーし、イメージを作成しません）。バックアップを作成するたびに、dirvishは保存するディレクトリツリーの完全なコピーを個別に作成します。

トリックは、保存しているツリーの古いバックアップコピーがあることをdirvishが検出すると、新しいツリーに古いツリーのファイルへのハードリンクを作成することにより、変更されていないファイルを自動的に再利用することです。

このように、各バックアップコピーは完全な自己完結型のディレクトリツリーのコピーですが、同時に変更されたファイルのみがファイルシステムのスペースを実際に占有します。つまり、増分バックアップ（スペース節約）とフルバックアップ（簡単な取得）の利点を同時に得ることができます。

これは、ハードリンクがユーザースペースツールに対して完全に透過的であるためにのみ可能です。

これはおそらくシンボリックリンクでも動作します（ただし、シンボリックリンク自体を使用するデータをバックアップすると問題が発生します）が、ハードリンクでのみ可能な1つの利点は次のとおりです。

古いバックアップを破棄する場合は、対応するバックアップディレクトリツリーを削除するだけです。そのツリーからのみリンクされたファイルは、ファイルシステムによって自動的に削除されます（最後のハードリンクが削除されるため）が、他のコピーにも表示されるファイルはディスクに残ります。

たとえば、大きな一時tarballをダウンロードする必要があるプログラム（またはスクリプト）があり、それを抽出した後、プログラムはすぐにそれを削除します。

何らかの理由で将来使用するためにそのtarballを保持したい場合ln /tmp/tarball.tgz ~、tarballがまだダウンロードされている間に最善の方法があります。その後、何もする必要はありません。

ダウンロードが終了し、プログラムが「元の」ものを削除した後でも、正確なコピーはまだホームディレクトリにあるはずです。

「ハードリンク」を使用して、「HowTo」とスニペットの一部をバックアップします

ユーザー/ルートに「共有ドキュメント」という名前のディレクトリがあります。そのディレクトリには、適切なディレクトリにあるヒント、トリック、スニペット、ハウツーへの「ハードリンク」があります。php、mysql、css、regex、formulas、linuxなど。「1か所」に配置することで、使用しやすくなります。頻繁に使用するドキュメントを探してDocuments /ディレクトリにジャンプするよりも、更新しやすくなります。

ずっと前に、私はシンボリックリンクを使用しました。この共通の「共有ドキュメント」ディレクトリをサーバーに忠実にバックアップします。問題は、シンボリックリンクまたは「ソフトリンク」、コピー（cp -auv）またはtarコピーおよびコピーした場合、ドキュメントの内容ではなく「リンク」のみをバックアップまたはコピーすることです。そのため、ディレクトリを走査して、実際の場所から2ダースのファイルをそれぞれコピーする必要があります。

ハードリンクを使用すると、 'Shared Docs'ディレクトリをコピー、tar、rsyncし、広く分散したドキュメントを実際に自信を持ってバックアップできます。コンテンツは実際にバックアップされます。0バイトの「リンクファイル」をバックアップし、情報をバックアップしていないことに気付いたとき、それは本当にうんざりしていました。

「ハードリンク」を使用することのマイナス面は、ディレクトリでlsを実行しても、ファイルが別のファイルと「リンク」されていることや、そのファイルが共存する可能性があることを示していないことです。それらを見つける方法はありますが、単純なls -l->が指すことでは明らかではない、と言っているので、通常、ドキュメントの先頭にこのディレクトリ/ファイル「このファイル」を示すメモを追加します'は「共有」されています

ランディス。