/ binにシンボリックリンクとハードリンクが混在しているのはなぜですか?


10

私はシンボリックリンクとハードリンクの技術的な違いを理解しています。これは実際の使用に関する質問です。特に、両方が一見似たような条件で使用される理由を知りたいと思い/binます。ディレクトリです。

これが私のシステムでのリストのフラグメントです:

~$ ls -lai /bin
total 10508
32770 drwxr-xr-x  2 root root    4096 Jun 14 11:47 .
    2 drwxr-xr-x 28 root root    4096 Sep  6 13:15 ..
  119 -rwxr-xr-x  1 root root  959120 Mar 28 22:02 bash
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bunzip2
  127 -rwxr-xr-x  1 root root 1832016 Nov 16  2012 busybox
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzcat
 6191 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzcmp -> bzdiff
 5640 -rwxr-xr-x  1 root root    2140 Dec 15  2011 bzdiff
 5872 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzegrep -> bzgrep
 3520 -rwxr-xr-x  1 root root    4877 Dec 15  2011 bzexe
 6184 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzfgrep -> bzgrep
 5397 -rwxr-xr-x  1 root root    3642 Dec 15  2011 bzgrep
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzip2
 2851 -rwxr-xr-x  1 root root   10336 Dec 15  2011 bzip2recover
 6189 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzless -> bzmore
 5606 -rwxr-xr-x  1 root root    1297 Dec 15  2011 bzmore

見やすくするために、同じiノードへのハードリンクをインデントしました。だから、シンボリックリンクがある場合に使用されているbzcmpbzegrepbzfgrepbzlessの場合とハードリンクbzip2bzcatbunzip2

これらはすべて(ディレクトリではなく)通常のファイルであり、1つのファイルシステム内に常駐し、システムユーティリティであり、bzipアーカイブという同じものを操作するために作成されています。この特定のケースでハードリンク/シンボリックリンクを使用する理由は純粋に歴史的なものですか、それとも何か不足していますか?

私の質問の明確化:

私は尋ねていません

  • シンボリックリンクとハードリンクの技術的な違い
  • それぞれの理論的な長所と短所

これらの質問は、SOの他のスレッドで対処されています。特定のケースで関連するシステムユーティリティのグループについて異なる決定が行われた理由を理解しようとしています。技術的には、それらはすべてシンボリックリンクまたはハードリンクである可能性があり、両方のオプションが機能します(どちらの場合も、プログラムはを介してどのように呼び出されたかを把握できますargv[0])。ここに意図があれば理解したいと思います。

関連:


それはパッケージメンテナーが決めることだと思います。私はgentooを実行してい/binて、私の3番目の列ls -laiは常にな1ので、ソフトリンクのみを使用しているようです。どのディストリビューションを使用していますか?
2013

私はUbuntu 12.04を使用しています
Dmitry Pashkevich

1
一見すると、「バイナリのハードリンク、スクリプト/ラッパーのシンボリックリンク」のような規則があるように見えます。
peterph 2013

回答:


5

ハードリンクとシンボリックリンクを使用する理由

このシナリオでシンボリックリンクよりもハードリンクを使用することには、主に3つの利点があります。

ハードリンク

  1. ハードリンクでは、リンクはiノードを直接指します。
  2. ハードリンクは、実行可能ファイルの複数のコピーを持つようなものですが、1つのディスクスペースのみを使用します。
  3. ハードリンクのどちらのブランチも、何も壊さずに名前を変更できます。

シンボリックリンク

  1. リンクはオブジェクトを指します(オブジェクトは次にiノードを指します)。
  2. それらはファイルシステムにまたがることができますが、ハードリンクはできません。

一般的なリンクの利点

これらのリンクが存在するのは、多くの実行可能ファイルがそれらの呼び出し方法に基づいて異なる動作をするためです。例えば、2つのコマンドbzlessbzmore、実際には単一の実行可能ですbzmore。実行可能ファイルは、それを呼び出すために使用された名前に応じて異なる動作をします。

これはさまざまな理由で行われます。以下に、より明白なものをいくつか示します。

  1. 多くではなく単一の実行可能ファイルを開発する方が簡単
  2. ディスク容量を節約
  3. 展開が簡単

なぜ両方が使用されているのですか?

この特定のアプリケーションでは、どちらを選択しても意味がありません。どちらも、エイリアスとして機能する機能を促進して、単一の実行可能ファイルをオーバーロードすることができます。これは、ここのさまざまなプログラムの開発者が実際に利用している重要な機能です。

FHS(Filesystem Hierarchy Standard)を見ると、このように指定されていても、どちらでもかまいません。

抜粋

/ bin / shが本当のBourneシェルでない場合は、実際のシェルコマンドへのハードリンクまたはシンボリックリンクである必要があります。

これの背後にある理論的根拠は、shとbashが必ずしも同じように動作するとは限らないためです。シンボリックリンクを使用すると、ユーザーは/ bin / shが本当のBourneシェルではないことを簡単に確認できます。

...

...

gunzipおよびzcatプログラムが存在する場合、それらはgzipへのシンボリックリンクまたはハードリンクである必要があります。/ bin / cshは、/ bin / tcshまたは/ usr / bin / tcshへのシンボリックリンクの場合があります。

参考文献


ええ、わかりました。でも、なぜシンボリックリンクが使用されたり、ハードリンクが使用されたりするのですか?あなたが説明したことはどちらの場合でも同じように機能します
Dmitry Pashkevich

@DmitryPashkevich-OK私は私の答えをリファクタリングしました、それがより良いかどうか私に知らせてください。
slm

多分私はばかげた質問をしているのですが、それでもまだ答えられていないと感じます:)はい、私は2種類のリンクの技術的な違いと長所/短所に精通しています。特定のケースを理解しようとしてい/bin/ます。ディレクトリにハードリンクとシンボリックリンクの両方が表示されるのはなぜですか?これらのユーティリティの開発者が1つのリンクタイプに固執しなかったのはなぜですか?
ドミトリー

(できれば)明確にするために元の質問を編集しました
Dmitry Pashkevich

@DmitryPashkevich-いくつかの追加コンテンツを追加しました。それが役立つかどうか私に知らせてください。
slm

5

既存のプラクティスから、どの種類のリンクを使用するかを指示する非技術的なルールがあるかどうかを理解しようとしているようです。(私が言う非技術系すでに他の上で1つを使用するための技術的な理由を知っているので。)

答えは、他にルールはありません。あなたがUbuntuのbzip2パッケージから指摘したこの例は、多くの開発者が多くの予見なしにそれらを混ぜ合わせていることを示しています。これは、技術的な違い以外に強力なガイダンスはなく、それらの違いは小さいためです。

個人的に、私は常にシンボリックリンクを使用することを好みます。なぜなら、私は彼らの自己文書化の性質と引き換えに、彼らの小さなオーバーヘッドを支払う用意があるからです。

他の開発者は、提供する小さな効率のためにハードリンクを選択します。

この問題は、スペースとタブ動的と静的、またはEmacsとviのようによく似ていますが聖なる戦争を引き起こすほど面白くはありません。より興味深い戦闘と同様に、どちらのオプションを選択するかには理由がありますが、どちらを使用するかを誰かに指示されない限り、より意味のあるものを選択できます。


1
ご意見をお寄せいただきありがとうございます。シンボリックリンクの「自己文書化」の性質は、しばしば見過ごされがちなものだと思います
Dmitry Pashkevich
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.