共有度のバラエティが変わらない場合でも、 ファイルがあるレベルの共有度から別のレベルの共有度に移ることはありえます。 もし共有度の変更が名前を変更するということになれば、 そのファイルへのアクセスは失われます。 以下の 2つの例を見てください。
最終的に Sun は自分のおかした間違いを理解しました。 Sun がカーネルに特化したファイルを作って、 別の共有を導入したときは、 /usr/sbin/adb -> /usr/kvm/adb のようなシンボリックリンクを作って、システムが動かなくなることのないようにしました。
共有度によってアクセスするファイルの名前を決めるという考え方は、間違っています。 共有度は、一定ではないのです。 名前は、一定でなければなりません。
/package はどのようにファイル共有をサポートするのでしょうか? 答え: ファイル共有をしているシステムでは、 パッケージマネージャはそのシステムに特化された設定ファイルと、 パッケージにふくまれるわずかな共有情報を使って、 適切なシンボリックリンクを自動的に用意することができます:
/package/admin/daemontools-0.76/src -> /shared/dist/admin/daemontools-0.76/src /package/admin/daemontools-0.76/package -> /shared/dist/admin/daemontools-0.76/package /package/admin/daemontools-0.76/compile -> /shared/syst/openbsd-i386/admin/daemontools-0.76/compile /package/admin/daemontools-0.76/command -> /shared/syst/openbsd-i386/admin/daemontools-0.76/commandけれどもこれに注意する必要があるプログラムは、パッケージマネージャだけです。 これらのファイルは共有度を無視してアクセスされます。
ファイル共有をしていないシステムでは、 /shared に悩まされる理由はまったくありません。 愚かなる者たちよ、ものごとは単純にしておきなさい。
パッケージを作るときに、 package/sharing というファイルをつくれば、ファイル共有をサポートすることができます。 これはどのディレクトリがどの共有度レベルであるかを宣言するものです。 たとえば、 /package/admin/daemontools-0.76/package/sharing というファイルはこうなっています:
command:syst compile:syst package:dist src:dist現在のところ定義されている共有度レベルは次のとおり:
/etc/passwd でたびたび使われる #! ラインでしばしば使われる ppplogin シェルスクリプトについて perl 実行可能ファイルについて 考えてみる。 考えてみる。 シェルスクリプトは、Emacs スクリ 実行可能ファイルは、バイナリ プトと同じように /usr/share の ファイルと同じように /usr の 共有度をもっている。つまり読み込み 共有度をもっている。つまり読み込み 専用であり、アーキテクチャに依存 専用であり、アーキテクチャに依存 しない。 する。 しかし、もし ppplogin をシェルス しかし、もし perl が特定の CPU の クリプトからコンパイル済のプログ 種類ごとに別々にコンパイルされて ラムに変更したらどうなるだろうか? いたらどうなるだろうか? 突如これは 突如これはアーキテクチャ依存に CPU に特化した共有度になるのだ。 なるのだ。したがって /usr の これは /usr よりもさらに共有しにく 共有度をもつことになる。 いものになる。 もしあなたが、この共有度の変更は もしあなたが、この共有度の変更は そのファイルにアクセスする名前を そのファイルにアクセスする名前を 変えることで実現すべきだと 変えることで実現すべきだと おろかにも主張するならば、 おろかにも主張するならば、 /etc/passwd における ppplogin の #! 行における perl の 使用は _おかしくなってしまう_。 使用は _おかしくなってしまう_。 プログラムは動かなくなるのである。 プログラムは動かなくなるのである。 どうやってこの問題を解決すべきか? どうやってこの問題を解決すべきか? ppplogin はシェルスクリプトで perl は /usr の共有度をもっているので あって、それをコンパイルされた あって、それを特定の種類の CPU ごとに プログラムで置き換えることは コンパイルすることは間違っていると、 間違っていると、大声で叫ぶべきなの 大声で叫ぶべきなのだろうか? だろうか? /etc/passwd に間接参照の #! 行に間接参照の層を追加して、 層を追加して、login プログラムが カーネルがいくつかの場所にある いくつかの場所にある ppplogin を perl を探すようにすべきなのだろうか? 探すようにすべきなのだろうか? もちろんそうではない。単に もちろんそうではない。単に ファイルには一定の名前を与えれば ファイルには一定の名前を与えれば よい。その物理的な場所、とくにその よい。その物理的な場所、とくにその 共有度を変更する必要があるときは 共有度を変更する必要があるときは シンボリックリンクを使えばよいの シンボリックリンクを使えばよいの である。しかしある名前でその である。しかしある名前でその ファイルにつねにアクセスできるよう ファイルにつねにアクセスできるよう 保証する必要がある。 保証する必要がある。 ------------------------------------------------------------------------ どこも論争になるところはありません。一定の決まった名前は誰からも好まれるのです。 誰もが ppplogin や perl を、それが /usr より共有度が高くても低くても /usr からアクセスできるのです。共有の問題はシンボリックリンクによって 解決します。それ以外の間接参照メカニズムは必要でもありませんし、 望まれてもいません。 これで「共有度は一定でない」ことの意味が明らかになったと思います。 マシン依存のファイルやマシン非依存のファイルには別々の名前空間を 使うことは --- システムパッケージとサードパーティのパッケージに別々の 名前空間を使うのと同様に --- 他のプログラムが長期にわたる名前でその ファイルにアクセスするのを妨害してしまいます。