ハードリンクの使用例？
ソフトリンクではなくハードリンクを使用したい状況はありますか？個人的には、ソフトリンクよりもハードリンクを使用したいという状況に出くわしたことはありません。また、ウェブを検索するときに遭遇した唯一の使用例は、 重複する同じファイルの重複です。 。
BTRFSボリュームのスナップショットも含まれていると私が思う別のコメントで言及されているバックアップの使用法は別として、ソフトリンク上のハードリンクの使用例は、タグでソートされたファイルのコレクションです。 （コレクションを作成するための最良の方法であるとは限りません。データベース駆動型の方法が潜在的に優れていますが、適度に安定している単純なコレクションの場合、それほど悪くはありません。）
すべてのファイルが1つのフラットなディレクトリに保存され、さまざまな基準（年、主題、アーティスト、ジャンルなど）に基づいて他のディレクトリに分類されるメディアコレクション。これは、個人の映画コレクション、またはコマーシャルスタジオの集合である場合があります。動作します。基本的にファイルは保存され、変更される可能性はほとんどなく、おそらくリンクによって複数の場所にソートされます。
「オリジナル」と「コピー」の概念はハードリンクには適用されないことに注意してください。ファイルへのすべてのリンクisオリジナル、通常の意味での「コピー」はありません。ただし、ユースケースの説明では、用語は動作のロジックを模倣しています。
「オリジナル」は「カタログ」ディレクトリに保存され、ソートされた「コピー」はそれらのファイルにハードリンクされます。並べ替えディレクトリのファイル属性をr/oに設定して、ファイル名と並べ替えられた構造が誤って変更されるのを防ぎ、カタログディレクトリの属性をr/wにして、必要に応じて変更できるようにすることができます。 （そのためのケースは、一部のプレーヤーがメディアファイルに埋め込まれたタグに基づいて、ユーザー入力またはインターネット検索からファイルの名前を変更して再編成しようとする音楽ファイルです。）さらに、「コピー」ディレクトリの属性は、 「元の」ディレクトリでは、ソートされた構造をグループまたは全世界で利用できますが、アクセスは制限されていますが、メインの「カタログ」には、完全なアクセス権を持つプリンシパルユーザーのみがアクセスできます。ただし、ファイル自体は、そのiノードへのすべてのリンクで常に同じ属性を持ちます。 （ACLは、それを強化するために探索できますが、私の知識領域ではありません。）
オリジナルの名前が変更されたり移動されたりした場合（たとえば、単一の「カタログ」ディレクトリが大きくなりすぎて管理できなくなるなど）、ハードリンクは有効なままであり、ソフトリンクは壊れます。 「コピー」が移動され、ソフトリンクが相対である場合、ソフトリンクは再び壊れ、ハードリンクは壊れません。
注：ソフトリンクが関係している場合、さまざまなツールがディスク使用量を報告する方法に一貫性がないようです。ただし、ハードリンクを使用すると、一貫性があるように見えます。したがって、「タグ」のコレクションに分類されたカタログ内の100個のファイルがある場合、500個のリンクされた「コピー」を簡単に作成できます。 （写真コレクションの場合、日付、写真家、平均3つの「件名」タグなど。）たとえば、イルカは、ハードリンクの場合は100ファイル、ソフトリンクを使用する場合は600ファイルとして報告します。興味深いことに、どちらの方法でも同じディスク領域の使用量が報告されるため、ソフトリンクの場合は小さなファイルの大きなコレクション、ハードリンクの場合は大きなファイルの小さなコレクションのように見えます。
このタイプの使用例の注意点は、COWを使用するファイルシステムでは、「オリジナル」を変更するとハードリンクが壊れることがありますが、ソフトリンクは壊れないということです。ただし、マスターコピーを作成することが目的である場合、編集、保存、および並べ替えを行った後、COWはシナリオに入りません。
ハードリンクは、両方のファイルの存在を結び付けたくない場合に役立ちます。このことを考慮：
touch a
ln -s a b
rm a
bは役に立たなくなりました。 （そして、これらのステップはかなり離れた場所で行われるかもしれませんし、別の人によって行われるかもしれません。）
一方、ハードリンクでは、
touch a
ln a b
rm a
bはまだ存在し、正しいです。
単一のプログラムは、起動する名前に応じて、その動作を変更する場合があります。
$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x 2 root bin 19144 Jul 26 2016 /usr/bin/pgrep
208330 -r-xr-xr-x 2 root bin 19144 Jul 26 2016 /usr/bin/pkill
ソース のどちらが終わるかは、次のような方法で決定されます
if (strcmp(__progname, "pgrep") == 0) {
action = grepact;
pgrep = 1;
} else {
action = killact;
正確な詳細は、関係するOSと言語によって異なります。
これにより、（ほとんど）同一のコードを2つの（ほとんど）同一のバイナリにコンパイルする必要がなくなります。 StevensによるとAPUEの第4章のシンボリックリンクは、BSD4.2（1983）でハードリンクのさまざまな制限を置き換えるために実装されていましたが、UNIXの日付からディスクスペースが非常に高かった日までのことを覚えておいてください。プログラム名としてシンボリックリンク名が使用されているかどうかを確認するテストプログラムは、次のようになります。
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("called as '%s'\n", *argv);
exit(0);
}
そしてを介してテスト：
$ cc -o myname myname.c
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$
P2Pソフトウェアが特定のファイルのダウンロードを完了すると、そのファイルは特定のディレクトリに配置されます。ダウンロードしたファイルを編集する必要はほとんどありません。一般的なケースは、ファイルが必要な別のディレクトリにハードリンクを作成することです。
利点：
- 「コピー」を
rmまたはmvした場合でも、必要に応じてP2Pネットワークでファイルを共有します。 - ファイルは、必要なパスにもあります。そのような場所のほとんどは共有されません。
- 「元の」ファイルを
rmすることで、ファイルの共有を停止できます。この操作は、目的の場所の「コピー」には影響しません。 - 私のディスクスペースは一度だけ使用されます。
要点：最初にrmにするファイルを事前に知っていれば、シンボリックリンクを使用するかもしれません。しかし、私は知りません。
ファイルシステムは、ファイルを整理および分類するためのシンプルでありながら効率的な方法です（これが存在の主な理由です）。ハードリンクを使用すると、この点でより高度な柔軟性が得られます。
前述のように、ハードリンクを処理する場合のオリジナルとコピーの概念はありません。すべてのディレクトリエントリ（ハードリンク）は、優先順位のないファイル（そのiノードを指す）の存在への単なる参照なので、壊れたハードリンクもありません。 。
したがって、ここにはハードリンクが参加するであるがソフトリンクが参加しないのユースケースがいくつかあります。
映画や音楽、その他のメディアのコレクションがあり、ブランチのアーティストごとに分類された曲など、さまざまな分類基準を適用したいとします（各アーティストには独自のサブディレクトリがあります）。別のブランチ（別のサブディレクトリにあるなど）のジャンル別など。ファイルを複製したり、「オリジナル」を配置する場所を決定したりせず、「壊れたリンクを回避するために、移動時にファイルを管理および再リンクします。
もう1つの理由は、同じファイルの複数のコピーを保持するために必要なストレージスペースの浪費を避け、
chrootsyscallが「マスター」ファイルシステムルート（シンボリックリンク）内のファイルのサブセットからメリットを得られるようにすることです相対パスがある場合でも、chrootサンドボックスの外部からファイルを参照することはできません）。ハードリンクが存在する非常に重要ですが、めったに言及されないもう1つの理由は、
..サブディレクトリです。..ディレクトリは実際には（ほとんどのUNIX fs実装では）親ディレクトリへのハードリンクです。ハードリンクがない場合、これは完全に異なる方法で実装する必要がありますが、ハードリンクの存在により、これは非常に簡単に実装できます。
ハードリンクを必要とする非常に一般的な実例：
git clone --reference <repository>
これは、コピーがほとんどないローカルGitリポジトリからクローンを作成します。オブジェクトファイル（Gitが「データベース」として使用する不変のファイル）をコピーする代わりに、単純にハードリンクします。
任意のリポジトリはオブジェクトを削除できますが、iノードは残りのリポジトリに対して有効なままです。オブジェクトがすべてのリポジトリから削除されると、ディスクから削除されます。ハードリンクは、美しく堅牢で高速なソリューションを実現します。 CIサーバーでは非常に一般的です。
非ハードリンクバージョンがあります：git clone --shared <repository>。ただし、これは気まぐれで、全員が同じディレクトリで作業しているため、さらに多くの警告があります。
私は最近、uImageがブートするイメージを指すソフトリンクである、U-Bootベースのシステムのやや安全な更新手順のユースケースを持っていました。停電は問題を引き起こさないはずであり、プロセスのどの時点で問題が発生するか（ファイルシステムが一緒に再生すると仮定）：
ln image.bin backup_image.bin
ln -sf backup_image.bin uImage
// replace image.bin
ln -sf image.bin uImage
rm backup_image.bin
ハードリンクなしではそれほど簡単ではありません。
/編集：
コメントのおかげで、次のようにした方がよいことがわかりました。
ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
// replace image.bin
ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin
（rmは、奇妙な状態をうまく回避できるようにするためにここにあります。たとえば、uImageがmvを失敗させる予期しないものである場合[ただし、必ずしも以前のln -sf 解決]。）
BackupPC は、サーバー上のハードリンクを使用してファイルレベルの重複排除を提供するバックアップシステムです。
ファイルはまず、md5ハッシュに基づいて「プール」ディレクトリツリーに格納されます。そのファイルを使用するバックアップは、プールファイルへのハードリンクを作成します。バックアップが期限切れ/削除されると、それらのハードリンクはファイルシステムから削除されます。
ハードリンクは自動参照カウントを提供するため、ここではソフトリンクよりも優れています。 cronジョブは、複数のリンクを持たないプールディレクトリ内のファイルを定期的に削除します。
この方法にはいくつかの欠点があります（主に、ファイルシステムベースのツールを使用してバックアップストアを複製するのが難しい）が、実際には非常に堅牢であることが証明されています。
別の使用例：Tomcat Java Webアプリケーションサーバーはファイル名をメタデータとして扱います。AJava "war"ファイルは、Web上のパスに基づいて名前を付ける必要がありますサーバ。
例：foo.warはJava URLを提供するコード/foo
残念ながら、この決定を行う前にシンボリックリンクを解決します。
したがって、アプリケーションビルドをデプロイし、わかりやすいファイル名（リリース番号や日付など）を付けたいとします。あなたはできません「実際の」名前のファイルへのシンボリックリンクを作成します-ハードリンクを作成する必要があります。
foo.warにシンボリックリンクされたfoo-20170129.warが機能しない
foo.warにハードリンクされましたfoo-20170129.war機能します。
このTomcatの動作は好きではありませんが、ハードリンクを使用すると回避できます。
私がハードリンクに使用した1つの用途は、壊れたファイルをダウンロードまたは解凍するときです。ダウンロードまたは圧縮解除を行うプログラム（unzipやunrarなど）は、エラーが発生したときに不完全なファイルを自動的に削除することが多く、通常はそれを保持するオプションはありません。ファイルを保持したい場合は、ハードリンクを作成できます。