ハードリンクの作成はいつ役に立ちますか？
ハードリンクには基本的に2つの主な制限があります。
- ハードリンクでは通常、リンクとファイルが同じファイルシステムに存在する必要があります。
- ディレクトリへのハードリンクを作成できるのはスーパーユーザーだけです。
したがって、ハードリンクの制限を回避するためにシンボリックリンクが導入されました。それで、問題は、ハードリンクがまだ必要かということです。それらがより役立つ状況があるかもしれませんか？
ハードリンクは、ファイルシステムをはるかに柔軟な方法で整理するのに役立ちます。基本的に、ハードリンクを使用すると、1つのファイルを取得して、ファイルシステム内の複数の場所に一度に配置できます。あなたが写真家で、たくさんの写真を持っているシナリオを考えてみてください（これは私の人生の例です！）。時々人々があなたにそれらの写真を求めるので、あなたはそれらに現れる人々によってそれらを整理するかもしれません。ただし、場所や日付で整理することもできます。これらの3つをネストする実際の方法はありません。これらは、完全に別個の組織軸です。したがって、これら3つの異なるものに対して3つの異なる階層を作成し、各写真を3つすべてに存在させることができます。なし各写真を3回保存する必要があります。それがハードリンクの魔法です。シンボリックリンクのリンクを解除します。「実際のファイル」がどこにあるかを心配する必要はありません。これらはすべて実際のファイルだからです。ファイルは参照がなくなるまで保持され、最後のハードリンクを削除すると削除されるため、自由に削除して移動できます。シンプルで、追跡する必要はあまりありません。
ファイルの内容は、すべてのハードリンク（はい、すべてのファイル名は最初のものも含めてハードリンクです）が消去され、ファイルが閉じられるまでパージされません。そのため、ファイルが複数の場所で必要な場合に役立ちますが、いつでもそれらのいずれかから削除できます。の間に ~/Downloads/coolsong.mp3および~/Music/Cool Song.mp3。
シンボリックリンクに対するハードリンクのそれほど重要ではない利点の1つは、ハードリンクのiノードに到達したときに、カーネルがファイルにアクセスするために行う処理がそれ以上ないことです。シンボリックリンクが検出されると、カーネルはリンク値を読み取り、ファイルのiノードに到達する前にディレクトリ構造をトラバースし続ける必要があります。違いは必ずしも簡単に測定できるとは限りませんが、これには時間がかかります。シンボリックリンク値の要素の1つがそれ自体シンボリックリンクである場合、それは本当に楽しいものになります。
ハードリンクにはいくつかの理由があります
- 最後の参照がなくなるまでファイルへの参照を保持する（Ignacioが指摘したように）
- ファイルをハードリンクすると、ファイルシステム内の1つのファイルのスペースしか占有しません（ファイルへの両方の参照は同じiノードを共有します）。したがって、ハードリンクは同じファイルシステム上にある必要があります。
したがって、ハードリンクを使用する理由の1つは、多くのスペースを節約するためです...
どちらの参照にも追加でき、データは共有ファイルに入れられます。他のファイルからの読み取り中に一方のファイル記述子に追加することもできます（例：tail -f）
ここに示す例の多くは有効ですが、ソフトリンクでも同様に機能します（たとえば、「複数の場所に1つのファイルが必要」という問題）。
ハードリンクが本当に役立つ良い例は、バックアップソフトウェアです Dirvish ：
Dirvishは、高速のディスクベースのローテーションネットワークバックアップシステムです。
Dirvishを使用すると、ファイルシステムの完全なイメージのセットを無人で作成および期限切れにして維持できます。ダルヴィーシュのバックアップボールトは、データのタイムマシンのようなものです。
Dirvishは、ファイルを別の（バックアップ）ファイルシステム（USBハードディスクなど）にコピーすることにより、ファイルシステムレベルでバックアップを作成します（つまり、ファイルをコピーし、イメージは作成しません）。バックアップを作成するたびに、dirvishは保存するディレクトリツリーの個別の完全なコピーを作成します。
秘訣は、保存しているツリーの古いバックアップコピーがすでに存在することをdirvishが検出した場合、新しいツリーに古いツリーのファイルへのハードリンクを作成することにより、変更されていないファイルを自動的に再利用することです。
このように、各バックアップコピーはディレクトリツリーの完全な自己完結型コピーですが、同時に、変更されたファイルのみが実際にファイルシステムのスペースを占有します。つまり、増分バックアップ（スペースの節約）と完全バックアップ（簡単な取得）のメリットを同時に得ることができます。
これが可能なのは、ハードリンクがユーザースペースツールに対して完全に透過的であるためです。
これはおそらくシンボリックリンクでも機能しますが（シンボリックリンク自体を使用するデータをバックアップすると問題が発生します）、ハードリンクでのみ可能な利点の1つは次のとおりです。
古いバックアップを破棄したい場合は、対応するバックアップディレクトリツリーを削除するだけです。そのツリーからのみリンクされているファイルは、ファイルシステムによって自動的に削除されます（最後のハードリンクが削除されるため）が、他のコピーにも表示されるファイルはディスクに残ります。
たとえば、大きな一時的なtarballをダウンロードする必要があるプログラム（またはスクリプト）があり、それを抽出した後、プログラムがすぐに削除する場合が便利です。
何らかの理由でそのtarballを将来の使用のために保存したい場合は、tarballがまだダウンロードされている間にln /tmp/tarball.tgz ~を実行するのが最善の方法です。その後、何もする必要はありません。
ダウンロードが終了すると、プログラムが「元の」ものを削除した後でも、正確なコピーはホームディレクトリに残っているはずです。
「ハードリンク」を使用して、「ハウツー」とスニペットの一部をバックアップしています
ユーザー/ rootに「SharedDocs」という名前のディレクトリがあります。そのディレクトリには、適切なディレクトリにあるヒント、トリック、スニペット、ハウツーへの「ハードリンク」があります。 php、mysql、css、regex、formulas、linuxなど。これらを「1か所」に配置すると、頻繁に使用するこれらのドキュメントを探してDocuments /ディレクトリを飛び回るよりも、はるかに使いやすく、更新できます。
ずっと前に、私はシンボリックリンクを使用しました。この共通の「共有ドキュメント」ディレクトリをサーバーに忠実にバックアップします。問題は、シンボリックリンクまたは「ソフトリンク」がコピーされた場合（cp -auv）、またはタール化されてコピーされた場合、「リンク」のみをバックアップまたはコピーし、ドキュメントのコンテンツはコピーしないことです。したがって、ディレクトリをトラバースして、実際の場所から20個のファイルをそれぞれコピーする必要があります。
ハードリンクを使用すると、「共有ドキュメント」ディレクトリをコピー、tar、rsyncして、広く分散しているドキュメントを自信を持って実際にバックアップできます。コンテンツは実際にバックアップされます。情報ではなく、0バイトの「リンクファイル」をバックアップしていることに気付いたとき、それは私にとって本当にひどいことです。
「ハードリンク」を使用することの欠点は、ディレクトリでlsを実行しても、ファイルが別のファイルに「リンク」されていることや、そのファイルが共存できる場所を示していないことです。それらを見つける方法はいくつかありますが、単純なls -l->ポイントでは明らかではないと言っています...したがって、私は通常、このファイルのディレクトリ/ファイルを示すメモをドキュメントの先頭に追加します'は'共有 '
ランディス。