PBO-FSについての概要
１．はじめに
まずここで始めに言いたいことは「UNIXって使い難い」ということです。いや、安定してるし、枯れてるし、良いOSだとは思うのですが、いかんせん設定ファイルが散らばっており、どこをどう設定すれば良いのかわかりにくいところがあります。この辺はWindowsでも変わらず、こちらでは逆に中身が良く見えず、主要な情報がレジストリに集中しており、使い難いということで、使い難い？という点に関しては変わらないところもありますが、テキスト設定ファイルメインでこれが散らばりまくっているUNIXよりは、まだWindowsのが使いやすいでしょう。
そもそも、最もシステム設定が簡単・シンプルで使いやすかったのは「ＤＯＳ」です。大抵、設定ファイルは実行プログラムと同じところに置いておいて、設定変更はエディタでちょっとファイル変えてやるだけ。で、exeと設定ファイルをセットで持ち運べば、どこのＰＣにもっていっても、設定変更不要で安定動作しました。
もちろんこれはシングルタスク・シングルユーザという古典的なＯＳだからできる話ですが、設定的には、アプリケーションの設定ファイルはそのアプリと同じところに置いた方が分かり易いはすで、管理も楽です。
さてさて、ではマルチユーザ環境やより複雑な環境でDOSのような使い心地を実現することはできないのでしょうか？Windowsの用に設定関連を一極集中させるというお間抜けな手法をとるしかないのでしょうか？これはファイルシステムを基盤としているUNIXには向かない方針に思えます。
ここで、よく考えてみると、アプリの実行ファイルと設定をいっしょに扱うということは、今流行りのオブジェクト指向の概念ではないのか？と気が付きます。ファイルの配置にオブジェクト指向の考え方を入れるとどうなるでしょう？
で、実際にこれの考えを発展させた結果できたファイルシステム（ＦＳ）がPBO-FSです。一種のオブジェクト指向ファイルシステムなんですが、オブジェクト指向におけるクラスや継承という概念をそのままは用いず、委譲というメカニズムに頼っているため、厳密にはオブジェクト指向ファイルシステムでなく、プロトタイプベースオブジェクトファイルシステムとなっています。
さてさて、これの基本となる概念は、既に書いたように、実行ファイルとそれが用いる各種のファイルを一緒のディレクトリに置いて使うというポリシーを貫くということです。実行ファイルはその実行ファイルが置いてあるディレクトリのファイルしか見に行きません。すると、ディレクトリがオブジェクトというわけですね。
しか〜し、これをやってしまうとお間抜けなことになります。たとえば、WindowsでWordのファイルを作ったら、全てのwordファイルの横にWord一式が置いてある必要があるわけですね(^^;
もちろん、DOSやWindowsで良くやったように拡張子の概念を用いるというのも一つの手ですがUNIXには合いません。
そのため、委譲リンクというUNIXのシンボリックリンクを拡張したリンク機構を新たに持ち込むことで、これに対応します。この委譲の概念は、オブジェクト指向のモデルの中で、プロトタイプベースと呼ばれる、あまりメジャーでないモデルに出てくる概念で、クラスの機能や継承の機能をこれで代用できます。まず、PBO-FSの新機能である、この委譲リンクの働きについて説明しましょう。
２．委譲リンク
委譲リンクは特殊なシンボリックリンクです。シンボリックリンクとしても働きます。ですので、例えば、ルートにaとbというディレクトリがあって、bの中にbfileというファイルがあり、aの中にlinkという名前の/bへのリンクを設けた場合、/a/link/bfileというファイル名でも、/b/bfileにアクセスできます。
ただ委譲リンクとシンボリックリンクの違うところは、この場合、/a/bfileという名前でも/b/bfileにアクセスできるということです。
どこが違う？もしくは、何の意味があるのか？と思ったと思いますが、たとえば、/aの中に、/bと/cへの委譲リンクがある状態だとしましょう。シンボリックリンクの時と違うのは、この様に複数のリンクを一つのディレクトリに入れると、「ディレクトリの合成が発生する」ということなんですな。/bと/c内のファイルは全て/aの中にもあるように見えますので、bの中のbflileとcの中のcfileが/aの中にあるように見えます。
さらに、/aの中には/bへのリンクがあり、/bの中には/cのリンクがある状態だとしましょう。委譲リンクの場合、再帰的にリンクをたどりますので、/cの中のファイルは全て、/bと/aの中にあるように見えます。ここで、/a /b /cの中に同じ名前のファイルがあったらどうなるか？その場合、リンク元が優先して使われます。/a /b /cに同じ名前のファイルがあれば、/aが優先、/bと/cなら/b優先ですね。
さて、この話はどこかで聞いたことがありませんか？これは、オブジェクト指向による多段継承と同じです。クラスＢがクラスＣから継承して、クラスＡがクラスＢから継承すると、クラスＡにはクラスＢとクラスＣのメンバがあるように見え、クラスＣのメンバよりクラスＢのメンバのが優先・・・という話と同じです。
では、先ほどの委譲リンクが二つあった場合は何に対応するのでしょう？これは、オブジェクト指向でいう、多重継承に対応します。
この様に、PBO-FSではシンボリックに似た委譲リンクという機構を持ち込むことで、ディレクトリレベルにおける継承機構を実現しています。
３．ファイルシステム配置に関するオブジェクト指向
さて、話を元に戻します。
ＤＯＳでやっていたように、実行プログラムと各種設定ファイルを同じディレクトリに置くということをUNIXでやるにはどうしたらよいでしょう。
まずどこかにルート権限などでこのファイル一式をどこかにおきます（これを/appとします）。となると各自がこれを使うときは？わざわざ丸ごとコピーでしょうか？
ここで、委譲リンクが使えるのであれば、空ディレクトリを一つ作って（~/aとします）、/appへの委譲リンクをその中に作ってやればよいのです。これで、~/aを/appとしても使えます。/app内部のアプリは、~/aの下のプログラム実行として用います。
では、もしこのアプリの設定ファイル（/app/app.ini）を変えたいとしたら？
デフォルト設定で良いのなら、そのままでも問題ありません。~/a/app.exeを起動すると、~a/app.iniを読みに行きますが、なければ委譲リンクの働きで委譲されますので、/app/app.iniを読みに行きます。もし自分専用の設定に書き換えたければ、~/a/app.iniファイルを作れば良いんですね。次の~/a/app.exe起動時には、/app/app.iniではなく、~/a/app.iniの方の設定ファイルを見に行きます。
次、もしこのアプリがワープロか何かで、ファイルをdata.txtという名前で出力するとしましょう。~/a/app.exeを起動すると、ここの中にセーブしに行きます。しかし、これでは一つしかデータがセーブできませんね。出力ファイル名をdata.txtで無くすれば良いだけですが、もっと良い手がある気がしませんか？
実は、~/bというフォルダを作って、~/aに委譲リンクを張るという手が使えます。~/aには/appへの委譲リンクがありますので、~/bでも中にapp.exeやapp.iniがあるように扱えます。そこで、アプリの起動は~/b/app.exeを実行（実体は/app/app.exe）。これの設定ファイルは~/a/app.iniを読みに行き、データファイルの保存は~/b/data.txtに行われるということになります。ここで、~/bの中には、実際にはdata.txtファイルだけ。
ということで、設定ファイルや実行プログラムは無駄を省きながらも、実行プログラムとデータファイルは同じところにあるように扱えるという環境が実現できます。これがPBO-FSの基本的な利用法です。
なお、PBO-FSのアプリの場合、実行プログラムと同じディレクトリにあるファイルを良くアクセスしますので、これを簡単に実現できるように、専用のメカニズムが準備されています。それは、セルフディレクトリというもので、従来のUNIXが各プロセス毎に持っていた、ルートディレクトリやカレントディレクトリと並ぶ新しいディレクトリ概念です。また、これは、ファイルのパス名規則を拡張することでもあります。UNIXでは、ファイル名が/で始まっていればルートディレクトリを検索しに行き（なお、UNIXでは/はプロセス毎に設定できます。anonymousアカウントなどそうでしょ？）、/がつかない（すなわち、相対パス）ならカレントディレクトリからファイルを検索します。
PBO-FSでは、もう一つ、セルフディレクトリ相対というファイル形式を新たに設け、::で始まるファイル名はセルフディレクトリ相対で扱われます。プログラムの中で、::data.txtなどとファイルを開くと、その実行プログラムと同じディレクトリにあるdata.txtファイルを見に行くわけです。
PBO-FSには、委譲リンクとセルフディレクトリ以外にもう一つ新しいメカニズムがあります。それはディレクトリレベルの情報隠蔽機構です。たとえばC++でしたら、クラスでpublicやprotected, privateというものが使えますよね？あれのファイルシステム版です。このファイルは、同じディレクトリ内のファイルからしかアクセスできない、などと設定することができます。これで、ディレクトリをオブジェクトとしてカプセル化して、情報隠蔽が可能となるわけです。今回のポリシー（プログラムは自分のいるディレクトリ内のファイルしかアクセスできない）を徹底すれば、ファイルの中身というのは、それを扱うプログラムのみのローカルな話になりますから、外に見せる必要は無くなるわけですね。そもそもこの概念の場合、ユーザさんは通常ファイルの存在を気にする必要はなくなります。全てオブジェクト（＝ディレクトリ）単位で考えて、そのオブジェクトを使いたいときは、そのオブジェクトのメソッド（＝中のプログラム）を起動すれば良いのです。中のデータメンバ（＝データファイル）のことはユーザさんは忘れることができます。データファイルの存在を気にするのは、実行プログラムを作るプログラマさんだけです。
また、他のディレクトリ内のファイルへのアクセスがもちろん必要となりますが、これに関してはオブジェクト指向の常識に従い、他のオブジェクトへのメッセージパッシング（＝他のディレクトリ内のプログラム実行）で対処します。ファイルへの直接アクセスは避けます。また、プログラム間の通信には、いつもの用に標準入出力経由でパイプやリダイレクションを用います。UNIXなら、このようなプログラム連結はお約束でしょ？
４．さいごに
と、以上がPBO-FSとこれによるUNIXのオブジェクト指向化の概要です。今のところはこれを実現するカーネルだけの状態ですが、このポリシーに従い、各アプリのファイル配置を見直せば、UNIXがオブジェクト指向OSとなるはずです。興味を持たれた方はぜひとも参加を。
なお、プロトタイプベースなオブジェクト指向というものですが、今回の例である程度分かったと思いますが、クラスを用いず、継承も用いないオブジェクト指向の１モデルです。普通のオブジェクト指向におけるクラス-インスタンスの関係と、クラス-サブクラスの関係を同じものと見なし、クラスとインスタンスを区別しません。そのため、普通のオブジェクト指向で発生するメタクラスの問題（クラスをインスタンスオブジェクトと見なすと、そのクラスがあるはずだ＝メタクラスで、メタの無限階層）が発生しません。そもそもファイルシステムには抽象的な概念であるクラスの概念が存在しませんので、このプロトタイプベースの概念がうまく当てはまるわけですね。インスタンスの生成は、他のインスタンスのコピーとなり、PBO-FSではディレクトリの丸ごとコピーか、空ディレクトリ作って、その中に、プロトタイプとするディレクトリへの委譲リンク作成となります。