ハードリンクのユースケースは何ですか？ [閉鎖]

他のコメントで述べたバックアップ使用法（BTRFSボリュームのスナップショットも含むと考えています）に加えて、ソフトリンクを介したハードリンクの使用例は、タグごとにソートされたファイルの集まりです。 （コレクションを生成する最良の方法ではなく、データベースベースのアプローチがより良いかもしれませんが、かなり安定した単純なコレクションの場合は悪くありません。）

すべてのファイルが単一のディレクトリに保存され、さまざまな基準（年、トピック、アーティスト、ジャンルなど）に基づいて異なるディレクトリに分類されるメディアコレクション。これは個々の映画のコレクションであっても、商業スタジオの作品のコレクションであってもよい。デフォルトでは、ファイルは保存および変更される可能性がなく、並べ替えられ、複数の場所へのリンクを介して保存できます。

「オリジナル」と「コピー」の概念はハードリンクには適用されません。つまり、ファイルへのすべてのリンクには適用されません。はい一般的な意味の「コピー」はありません。ただし、ユースケースの説明では、これらの用語はアクションロジックを模倣します。

「オリジナル」は「カタログ」ディレクトリに保存され、ソートされた「コピー」はこのファイルにハードリンクされます。ソートディレクトリのファイルプロパティをr / oに設定すると、ファイル名とソート構造が誤って変更されるのを防ぎ、カタログディレクトリのプロパティを必要に応じて変更できるようにr / wに設定できます。 （これは、一部のプレーヤーがメディアファイルに含まれるタグ、ユーザー入力、またはインターネット検索に基づいてファイルの名前を変更して再構成しようとする音楽ファイルの場合です。）ディレクトリ内のディレクトリで並べ替えられた構造は、制限されたアクセス権を持つグループまたはワールドで使用できますが、デフォルトの「ディレクトリ」はフルアクセス権を持つデフォルトユーザーのみにアクセスできます。ただし、ファイル自体は、対応する inode を指すすべてのリンクで常に同じ属性を持ちます。 （これを改善するためにACLをナビゲートできますが、これは私の知識領域ではありません。）

元のファイルの名前が変更または移動された場合（たとえば、単一の「ディレクトリ」ディレクトリが管理するには大きすぎる）、ハードリンクは引き続き機能しますが、ソフトリンクは失われます。 「コピー」が移動され、ソフトリンクが相対的である場合、ソフトリンクは再び切断されるが、ハードリンクは切断されない。

注：ソフトリンクに関して、さまざまなツールでディスク使用量を報告する方法に矛盾があるようです。しかし、ハードリンクの場合は一貫性があるようです。したがって、「タグ」コレクションに分類されたディレクトリに100個のファイルがある場合は、500個のリンク「コピー」が簡単にある可能性があります。 （日付、写真家、平均3つの「トピック」タグなどの写真集の場合）たとえば、Dolphinはハードリンクの場合は100個のファイルを報告し、ソフトリンクを使用している場合は600個のファイルを報告します。興味深いことに、どちらも同じディスクスペース使用量を報告するため、ソフトリンクされた小さなファイルの大規模コレクションとハードリンクされた大規模ファイルの小さなコレクションのように見えます。

このタイプのユースケースに関する注意点は、COWを使用するファイルシステムで「ソース」を変更すると、ハードリンクが壊れる可能性があるが、ソフトリンクは切断できないことです。ただし、目的が編集、保存、並べ替え後にマスターコピーを取得することである場合、COWはそのシナリオには入りません。

ハードリンクは、2つのファイルの存在をバインドしたくない場合に便利です。考えてみてください：

touch a
ln -s a b
rm a

今はb役に立ちません。 （これらの手順は互いに離れているか、他の人が行うことができます。）

ハードリンクを使用する場合、

touch a
ln a b
rm a

bまだ生きていて正確です。

これは多くの状況で便利です。一般的なものは重複排除です。

• ファイルシステム内では、例えばホームディレクトリの重複排除ツールは、コピーをハードリンクに置き換えることができます。これにより、他のファイルに影響を与えずに削除できるという点で、2つのファイルの一部の「独立性」が維持されます。反対側に表示されます（変更を実行するツールが「新しいファイルに保存して名前を変更する」戦略を使用しない限り）
• バックアップシステムでは、複数のスナップショットを維持するためにハードリンクが頻繁に使用されます。特定のファイルが毎日バックアップされると、バックアップシステムはすべてのコピーをハードリンクできます（ただし、いいえ元のバージョン）、これはスペース要件を減らし、各スナップショットがファイルシステムレベルで自己サポートされるようにします。

別のユースケースは、ファイルを別の場所で使用できるようにすることです。たとえば、「開発」位置に保持されるスクリプトがある場合は、そのパスのどこかにハードリンクできます。これにより、開発ディレクトリからスクリプトを削除しても引き続き使用できます。 （しかし、この場合、いくつかの考慮事項があります。パスに特定のバージョンを「インストール」するか、シンボリックリンクを使用する方が適切かもしれません。）

個々のプログラムは、開始名に応じて動作を変更できます。

$ 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;

具体的な内容は、関連するオペレーティングシステムと言語によって異なります。

これにより、（ほとんど）同じコードを2つの（ほとんど）同じバイナリにコンパイルする必要がなくなります。 APUE第4章のStevensによると、ハードリンクのさまざまな制限を置き換えるために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'
$ 

ファイルシステムは、ファイルを整理して分類する簡単で効果的な方法です（ファイルが存在する主な理由です）。ハードリンクは、これに関してより高いレベルの柔軟性を可能にする。

前述したように、ハードリンクを扱うとき、オリジナルとコピーの概念はありません。すべてのディレクトリエントリ（ハードリンク）はファイルの存在への参照であり（対応するインデックスノードを指す）、優先順位がないため、壊れたハードリンクはありません。接続。 。

ここにいくつかのユースケースがあります。参加するためのハードリンクしかし、ソフトリンクはありません:

1. 映画、音楽、またはその他のメディアコレクションがあり、四半期のアーティストごとの曲（各アーティストには異なる四半期のジャンル別のサブカテゴリがあります）など、さまざまな分類基準を適用したいとします。サブディレクトリ）など、まだファイルをコピーしたくなく、「ソースファイル」を保存する場所を決めたくないので、ファイルが破損するのを防ぐために、ファイルを移動するときに「管理」して再リンクすることなく自由に再分類できます。 。接続。

2. もう1つの理由は、システムコールが「基本」ファイルシステムルート（シンボリックリンクは外部ファイルを参照できない）のファイルサブセットから利益を得ることを可能にしながら、同じファイルの複数のコピーを持つために必要なストレージスペースを無駄にすることですchroot。防止することですchroot。相対パスがあります）。

3. ハードリンクが存在するもう一つの非常に重要ですが、ほとんど言及されていない理由はサブ..ディレクトリです。これらの..ディレクトリは実際には（ほとんどのunix fs実装では）親ディレクトリへのハードリンクです。ハードリンクがない場合はまったく異なる方法で実装する必要があり、ハードリンクがあれば簡単に実行できます。