ハードリンクの使用例？[閉まっている]

どのような状況で、ソフトリンクではなくハードリンクを使用したいでしょうか？私は個人的に、ソフトリンクよりもハードリンクを使いたい状況に出くわしたことは一度もありませんし、ウェブを検索するときに出会った唯一のユースケースは同一ファイルの重複排除です。

BTRFSボリュームのスナップショットも含まれていると思われる別のコメントで言及されているバックアップの使用は別として、ソフトリンクを介したハードリンクのユースケースは、タグでソートされたファイルのコレクションです。（必ずしもコレクションを作成するのに最適な方法であるとは限りませんが、データベース駆動型の方法は潜在的に優れていますが、合理的に安定した単純なコレクションの場合、それほど悪くはありません。）

すべてのファイルが1つのフラットなディレクトリに格納され、さまざまな基準、つまり年、主題、アーティスト、ジャンルなどに基づいて他のディレクトリに分類されるメディアコレクション。これは個人の映画コレクションまたはコマーシャルスタジオの集合体です。動作します。本質的に終了すると、ファイルは保存され、変更される可能性は低く、ソートされ、リンクによって複数の場所に保存される可能性があります。

「オリジナル」と「コピー」の概念はハードリンクには適用できないことに注意してください。ファイルへのすべてのリンクはオリジナルであり、通常の意味では「コピー」はありません。ただし、ユースケースの説明では、用語は動作のロジックを模倣しています。

「オリジナル」は「カタログ」ディレクトリに保存され、ソートされた「コピー」はこれらのファイルにハードリンクされます。ソートディレクトリのファイル属性をr / oに設定して、ファイル名とソートされた構造を誤って変更することを防ぎます。カタログディレクトリの属性はr / wで、必要に応じて変更できます。（そのためのケースは、一部のプレーヤーが、メディアファイルに埋め込まれたタグに基づいて、ユーザー入力またはインターネット検索からファイルの名前を変更および再編成しようとする音楽ファイルです。）さらに、「コピー」ディレクトリの属性「オリジナル」ディレクトリでは、アクセスを制限してグループまたは世界がソートされた構造を利用できるようにすることができますが、メインの「カタログ」はプリンシパルユーザーのみがアクセスできます。フルアクセスで。ただし、ファイル自体は、そのiノードへのすべてのリンクで常に同じ属性を持ちます。（ACLはそれを強化するために調査することができますが、私の知識領域ではありません。）

オリジナルの名前が変更または移動された場合（たとえば、単一の「カタログ」ディレクトリが大きすぎて管理できない場合）、ハードリンクは有効のままで、ソフトリンクは破損します。「コピー」が移動され、ソフトリンクが相対的な場合、ソフトリンクは再び壊れますが、ハードリンクは壊れません。

注：ソフトリンクが含まれている場合、さまざまなツールがディスク使用量を報告する方法には一貫性がないようです。ただし、ハードリンクでは、一貫性があるようです。そのため、カタログ内の100個のファイルを「タグ」のコレクションに分類すると、500個のリンクされた「コピー」を簡単に作成できます。（たとえば、写真コレクションの場合、日付、写真家、および平均3つの「サブジェクト」タグ。）たとえば、Dolphinは、ハードリンクの場合は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つの（ほとんど）同じバイナリにコンパイルする必要がなくなります。UNIXは、ディスクスペースが非常に高価だった時代にまで遡りますが、APUEの第4章のシンボリックリンクは、BSD4.2（1983）でハードリンクのさまざまな制限を置き換えるために実装されました。プログラム名としてシンボリックリンク名が使用されているかどうかを確認するテストプログラムは、次のようになります。

#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. 映画や音楽、またはその他のメディアのコレクションがあり、ブランチ内のアーティストによって分類された曲（各アーティストには独自のサブディレクトリがあります）など、さまざまな分類基準を適用したいとします。ジャンルごとに別のブランチ（それぞれ異なるサブディレクトリにある）など。リンクの破損を避けるために、移動時にファイルを管理および再リンクします。

2. 別の理由は、同じファイルの複数のコピーを保持するために必要なストレージスペースの浪費を避け、chroot「マスター」ファイルシステムルート内のファイルのサブセットからシステムコールを活用できるようにすることです（シンボリックリンクは外部からファイルを参照できませんchrootサンドボックス、彼らは）相対パスを持っている場合でも。

3. ハードリンクが存在する非常に重要だがめったに言及されていない別の理由は、..サブディレクトリです。..ディレクトリは、実際のハードリンクせずに、これはハードリンクの存在を実装するために、これは非常に簡単になりながら、完全に異なる方法で実装する必要があり、（ほとんどの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解決策ではない]。）

ハードリンクの用途の1つは、破損したファイルをダウンロードまたは圧縮解除するときです。ダウンロードまたは圧縮解除（unzipやunrarなど）を行うプログラムは、エラーが発生したときに不完全なファイルを自動的に削除することがよくあり、通常はそれを保持するオプションはありません。ファイルを保持したい場合は、ハードリンクを作成できます。

BackupPCは、サーバー上のハードリンクを使用してファイルレベルの重複排除を提供するバックアップシステムです。

ファイルはまず、md5ハッシュに基づいて「プール」ディレクトリツリーに格納されます。そのファイルを使用するバックアップは、プールファイルへのハードリンクを作成します。バックアップの有効期限が切れる/削除されると、それらのハードリンクはファイルシステムから削除されます。

ハードリンクは、自動参照カウントを提供するため、ここではソフトリンクよりも優れています。cronジョブは、複数のリンクを持たないプールディレクトリ内のファイルを定期的に削除します。

この方法にはいくつかの欠点があります（主に、ファイルシステムベースのツールを使用してバックアップストアを複製することは困難です）が、実際には非常に堅牢であることが証明されています。

別の使用例：Tomcat Webアプリケーションサーバーは、ファイル名をメタデータとして扱います。java「war」ファイルは、Webサーバー上のパスに基づいて名前を付ける必要があります。

例：foo.war URLを提供するJavaコード/foo

残念ながら、この決定を行う前にシンボリックリンクを解決します。

そのため、アプリケーションビルドを展開し、わかりやすいファイル名（たとえば、リリース番号や日付）を付けたいとします。「本当の」名前のファイルへのシンボリックリンクを作成することはできません -ハードリンクを作成する必要があります。

foo.warへのシンボリックリンクがfoo-20170129.war機能しない

foo.warfoo-20170129.war作品にハードリンクされています。

このTomcatの動作は好きではありませんが、ハードリンクを使用すると回避できます。