JP3756949B2 - ファイルシステムに記憶された情報に関する要求を処理する方法及び装置 - Google Patents

Description

本願明細書は著作権の保護に関する事項を含んでおり、この著作権所有者は出願書類の開示或はある部分を、特許庁に記録されているままに再生されることに異議を唱えなるものではないが、一方、どのような物にも著作権が及ぶと考えている。
発明の背景
本願発明は、オペレーティング・システム（ＯＳ）の一部としてファイルシステムに記憶された情報に関する処理要求を行う方法及び装置に関するもので、特に、マルチファイルシステムに対する要求を処理する方法及び装置に関するものである。
コンピュータのＯＳは、幾つかの異なる動作モジュールを含み、その様なモジュールの１つにファイルマネージャがある。このファイルマネージャはハードディスクや着脱可能なディスクのようなデータ記憶媒体上に位置しているデータの編成、読出し及び書き込み等を管理している。各記憶媒体は、記憶媒体のデータをアクセスするための、それ自身に関連したフォーマットを有しており、その様なフォーマットの一例としてHFS，MS-DOS FAT，ProDOS，High Sierra，ISO9660，UNIX等がある。フォーマットは物理的なディスクフォーマット、ネットワークサーバーアクセス・プロトコル等を包含している。最近までは、コンピュータはたった１つのフォーマットの下で構成された記憶媒体にアクセスすることができた。しかし、コンピュータが、マルチフォーマットを用いてデータにアクセスできるようにする傾向に有り、マルチフォーマットを用いて記憶媒体にアクセスできる少なくとも２つのシステムが現在利用可能である。
欧州特許出願０４１５３４６（Willman）は、媒体を識別できるファイルシステムを自動的かつ動的に実装できるマイクロソフトＯＳ／２のＯＳで使用できるシステムを開示している。このWillmanのコンピュータシステムでは、１つ或はそれ以上のデータ記憶装置と複数のファイルシステム・ドライバが、ファイルシステムがリンクされて構成されているデフォルト・ファイルシステムを含んで設けられている。各ファイルシステム・ドライバは、特別なフォーマットのファイルシステムをアクセスできる。コンピュータシステムは連続して全ての周辺機器をモニタし、周辺の記憶装置における媒体のいかなる変化をも検知している。データ記憶装置において媒体が変更されると、或いはコンピュータシステムがデータ記憶装置に最初にアクセスされると、ファイルシステムドライバのリストで特定された最初のファイルシステムドライバがロードされ、ボリューム識別子が媒体から読み出される。この時、ボリューム識別子の位置は、ロードされたファイルシステムドライバによって特定される。そして媒体から読み出されたボリューム識別子はファイルシステムドライバに関連する識別子と比較されて、識別子が一致すればそのファイルシステムドライバがマウントされる。一致しなければ、リンクされたファイルシステムドライバのリストで次のファイルシステムドライバがロードされる。リンクされたファイルシステムドライバのリストの各ファイルシステムドライバがテストされるまで、或いは一致が見つかるまで、この過程が繰り返される。一致が見つからなかった場合は、デフォルトファイルシステムがマウントされる。
このシステムは、柔軟性に欠けている。特に、この識別子はシステムに用いることができる全てのボリュームフォーマット用に共通して知られた位置になければならない。その代わりに、ボリュームフォーマットにおける柔軟性増加を提供するため、各ファイルシステムドライバにそのボリュームを識別する独自の方法をとらせるのが望ましい。
マルチファイルシステムにアクセスする他のシステムにマイクロソフト（TM）ウィンドウズ（TM）ＮＴオペレーティング・システムがある。このシステムでは、各ファイルシステムドライバが保持する複数のオブジェクトにメッセージが送られ、そのオブジェクトはその要求の主題に対応している。従って、もし特定の種類のメッセージの処理に変更が必要な場合、その変更は各ファイルシステムドライバごとに行われなければならない。
その他のファイルマネージャーとして、例えばアップルコンピュータ株式会社によって製造されたマッキントッシュ（TM）ブランドのコンピュータ上で用いられるシステム７ファイルマネージャが知られている。このシステム７では要求を受け取ると、そのファイルマネージャは、その要求がアップルマッキントッシュ（TM）が用いるＨＦＳ（階層ファイルシステム）ボリュームへアクセスするための要求とみなす。もしその記憶媒体がＨＦＳでなければエラーが発生し、ファイルマネージャは要求されたアクセスの実行を試みるコードにその要求を出力する。
様々なプロセッサ上で実行することができ、多くのオペレーティング・システムで使用可能な、並行かつ非同期デバイスマネージャーを利用できる、ポータブルバージョンのファイルマネージャを提供することが望ましい。さらに、従来のファイルマネージャーのアプリケーションプログラマ・インターフェース（ＡＰＩ）に下位の互換性（downward compatibility）を提供するファイルマネージャーを提供することが望ましい。説明として、アプリケーションプログラマ・インターフェース（ＡＰＩ）は、第三者がそのオペレーティング・システムと通信ができる仕様（specification）を提供するものとして定義される。例えば、本発明の背景において、ＡＰＩは第三者がファイルマネージャーと通信できる仕様を提供するものと定義される。
従来のオペレーティング・システムは、特定のタスクを行う別々のモジュールを含まない、一体型コード構造（monolithic code structure）を用いて作られた。問題が明るみに出たのは、変更するごとに全システムを再構築しなければならず、システムの改良が困難になったからである。さらに、専用（特権：privileged）モードで実行される全てのコードも問題となる。これは、システムの構成要素のいずれかがエラーの原因となる構成要素と衝突する恐れがあったためである。
上記に対する解決策は、システムからできるだけ多くの機能性を、より特権性（privileged）の低いモードで実行される別々のサービス（例えば、ファイルマネージャー、入力・出力マネージャー、スクリーンマネージャ等）に分けて、コードの中心部により最も特権（privileged）化された機能を実行させることであった。その中心部はサービスの全くの最小限の機能を提供していたので、これを修正しなければならないことは稀であった。他のサービスの各々は独立して構築されたので、これらの修正はより容易であった。こうしてシステムコードのほとんどが縮小した特権（privilege）の下で実行されたので、システムはより安定した。また、システムがより容易に修正されたため、にわかに新しいものの導入が容易となり、多くの新しい性能が加えられた。このため、現代のオペレーティング・システムは、代表的にはこの中心部構造に従って設計されている。
一体型（monolithic）オペレーティング・システム用の従来のＡＰＩは、全体的な状況（global state）に大きく左右される。そこで、このような環境において、全ファイルマネージャ−データが個々に保護されたアドレススペースにあり、プログラマーが確実なシステムに向けて将来移行できることを想定したファイルマネージャーのため、新たなＡＰＩを開発することが望ましい。
発明の要約
本発明は、セントラルディスパッチャ、要求源として機能するマルチインターフェース、マルチローダブル・フォーマット・エージェント・モジュール（MULTIPLE LOADABLE FORMAT AGENT MODULE）またはファイルシステムドライバ、ストア（記憶装置（メモリ））、共用ライブラリを用いるファイルシステムに記憶された情報に関する要求を処理するシステムに関する。
本発明に係るシステムは、ファイルシステムの実行及び与えられたパブリックインターフェースから共に独立するように、ファイルシステムに記憶された情報に関する要求を表すことができる一組の共通メッセージ構造を用いる。これらのメッセージ構造は、その機構の構成要素間における通信の共通原語として用いられる。
複数のインターフェースモジュール（数はいくつでも構わない）は、システムの他の構成要素に、異なるパブリックインターフェースを提供する。従って特定の環境用に書かれたソフトウェアが、その環境において標準であるインターフェースを用いることができる。コーリングプログラムはインターフェースモジュールに様々な記憶媒体へのアクセス要求（リクエスト）を送る。これらのインターフェースモジュールは、そういった要求を処理させるためディスパッチャへ送る。
ディパッチャはこの要求を受けると、ストアからリトリーブした（取り出した）要求についての情報を基に、複数のフォーマットエージェントの１つにその要求を転送する。各フォーマットエージェントは、特定のファイルシステムフォーマットを用いて記憶媒体にアクセスするよう適応している。フォーマットエージェントは、記憶媒体と通信しながらディスパッチャから要求を受け取り、その要求を処理する。その要求の処理が終了すると、フォーマットエージェントは、元のコーラ(Caller：要求発生元)に返送されるべき何らかの情報をディスパッチャに応答する。その要求を実行するのに関わるフォーマットエージェント全てが終了しディスパッチャに応答したら、ディスパッチャは要求を伝えるのに用いたインターフェースモジュールに応答し、元のコーラに返送されるべき何らかの情報を送る。インターフェースモジュールは、その情報をインターフェースに適当な形式に翻訳し、そのコーラに返送する。
フォーマットエージェントの内部機構の一部は、異なるモジュール間でも非常によく似ているため、本発明に係るシステムは、フォーマットエージェント全てが用いることができる共通した共用ライブラリを提供する。このライブラリは、実行モジュール間で共用できる共通機構の実行を含むので、これらのモジュールの展開が容易となる。
本発明の一実施例によれば、少なくとも１つのコーラが記憶媒体へのアクセスが要求できるよう適応しているコンピュータにおいて、前記記憶媒体は少なくとも１つのファイルシステムフォーマットの一つに従って構成されており、システムは前記記憶媒体へのアクセス要求を処理するために提供される。前記システムは、コーラから要求を受け取り、受け取った要求の主題の少なくとも一部に基いて、前記要求を送信するための適当な宛先(desitination)を複数の宛先の中から決定し、前記要求を前記適当な宛先に送信するインターフェース手段、前記記憶媒体にアクセスする要求を処理するための、前記ファイルシステムフォーマットに対応するフォーマットエージェント手段、前記フォーマットエージェント手段を識別する少なくとも１つの第１の識別子と、前記複数の宛先を識別する第２の識別子と、第２の識別子と第１の識別子間でマッピングを行うマッピング手段とを記憶する記憶手段、そして前記要求を前記インターフェース手段から受け取り、前記マッピング手段に応じて前記要求をフォーマットエージェント手段に送出するディスパッチ手段とを備える。
本発明の他の実施例によれば、記憶媒体へのアクセスを要求する少なくとも１つのコーラを持つファイルマネージャーと、少なくとも１つのファイルシステムフォーマットの１つに従って構成される前記記憶媒体と、コーラから要求を受け取り、受け取った要求の主題の少なくとも一部分に基いて、前記要求を送信するための適当な宛先を複数の宛先から決定し、前記要求を前記適当な宛先に送信する複数のインターフェースモジュールと、前記記憶媒体にアクセスする要求を処理するための、前記ファイルシステムフォーマットに対応する少なくとも一つのフォーマットエージェントモジュール、前記少なくとも１つのフォーマットエージェントモジュールを識別する少なくとも１つの第１の識別子と、前記複数の宛先を識別する第２の識別子と、第２の識別子と第１の識別子間でマッピングを行うマッピング手段とを記憶するストア、そして前記インターフェースモジュールから前記要求を受け取り、前記マッピング手段に応じて前記要求を前記少なくとも１つのフォーマットエージェントモジュールに転送するディスパッチモジュールとが提供される。
本発明の他の実施例によれば、コンピュータにおいて、少なくとも１つの記憶媒体へのアクセス要求を処理するディスパッチャを備え、前記コンピュータは、オペレーティングシステムと、前記要求を送信したコーラと前記オペレーティング・システム間をインターフェースするインターフェース手段と、そして前記オペレーティング・システムと前記記憶媒体間をインターフェースする複数のエージェントモジュールとを備え、各エージェントモジュールは少なくとも１つのファイルシステムフォーマットの１つに対応している。前記ディスパッチャは、前記少なくとも１つのエージェントモジュールを識別する少なくとも１つの第１の識別子と、要求を送信することができる複数のオブジェクトを識別する第２の識別子と、第２の識別子と第１の識別子間でマッピングを行うマッピング手段とを記憶するストアと、そして前記インターフェースモジュールから前記要求を受け取り、前記マッピング手段に応じて前記要求を前記少なくとも１つのエージェントモジュールに転送する要求処理モジュールとを備える。
本発明の他の実施例によれば、コンピュータにおいて、少なくとも１つの記憶媒体へのアクセス要求を処理する方法を提供するものであり、前記コンピュータはオペレーティングシステムと、前記要求を送信したコーラと前記オペレーティング・システム間をインターフェースするインターフェース手段と、前記オペレーティング・システムと前記記憶媒体間をインターフェースする複数のエージェントモジュールを備え、各エージェントモジュールは少なくとも１つのファイルシステムフォーマットの１つに対応している。前記方法は、前記複数のエージェントモジュールを識別する少なくとも１つの第１の識別子と、要求を送信することができる複数のオブジェクトを識別する第２の識別子と、第２の識別子と第１の識別子間でマッピングを行うためのマッピング情報とをストア（メモリ）に記憶する記憶行程と、そして前記インターフェースモジュールから前記要求を受け取る受信行程と、前記マッピング情報に応じて前記要求を前記少なくとも１つのエージェントモジュールに転送する転送行程とを含む。
本発明の他の実施例によれば、記憶媒体へのアクセスを要求する少なくとも一人のコーラを持つコンピュータにおいて、各記憶媒体は少なくとも１つのファイルシステムフォーマットの１つに従って構成されており、前記記憶媒体へのアクセス要求を処理する方法が提供される。前記方法は、少なくとも１つのフォーマットエージェント手段を識別する少なくとも１つの第１の識別子と、複数の宛先を識別する第２の識別子と、第２の識別子と第１の識別子間でマッピングを行うためのマッピング情報とを記憶手段に記憶する記憶行程と、インターフェース手段でコーラからの要求を受け取る受信行程と、要求の主題の少なくとも一部分に基づいて、前記要求を送信するための適当な宛先を複数の宛先から決定する決定行程と、前記要求を前記適当な宛先に送信する送信行程と、前記要求をインターフェース手段からディスパッチ手段で受け取る行程と、前記要求を、記憶手段のマッピング情報に応じて適当なフォーマットエージェント手段の１つに転送する行程と、前記ファイルシステムフォーマットに対応する前記フォーマットエージェント手段の１つを介して、前記記憶媒体へのアクセス要求を処理する行程とを含む。
さらに本発明の他の目的と特徴と利点は、以下の実施例の詳細な説明とそれに関連付けられた添付図面から当業者には明らかになるであろう。
【図面の簡単な説明】
本願の発明を、装置の好適な実施例と添付図面を参照してさらに詳細に説明する。
図１は本発明が実行できる典型的なコンピューターシステムを示すブロック図である。
図２は本発明によるファイルシステムに記憶される情報に関する要求を処理するファイルマネージャの構造全体を示すブロック図である。
図３ａは本発明の一実施例に係るストア（メモリ）の構成を示すブロック図である。
図３ｂと図３ｃはそれぞれ本発明の一実施例に係る制御ブロックヘッダとエージェント制御ブロックを表す図である。
図４は本発明の一実施例に係る共用ライブラリを表すブロック図である。
図５ａは本発明の一実施例に係るディスパッチャを示すブロック図である。
図５ｂは本発明の一実施例に係る要求タスク状況構造（request task state structrue）を表す図である。
図６は本発明の一実施例に基づいて、インターフェースがコーラ(caller)からの要求を処理する過程を示すフローチャートである。
図７ａ乃至図７ｆは本発明の一実施例に基づいて、ストアを形成する制御ブロックの存在を維持する、フォーマットエージェントによる処理を示すフローチャートである。
図８ａ乃至図８ｍは本発明の一実施例に係るディスパッチャ処理を示すフローチャートである。
詳細の説明
本説明において、ユーザとはある特定のソフトウエアの一部を使用する者、そして、コーラ(Caller：要求発生元)とは、本発明に於けるファイルマネージャを呼び出すソフトウエアの一部である。
本発明の目的は、セントラルディスパッチャと、コーラとディスパッチャ間のインターフェースとして機能するマルチプルインターフェースと、ファイルシステムフォーマットに従って大系づけられた記憶媒体にアクセスするためのマルチロード可能なフォーマットエージェントと、フォーマットエージェントとファイルシステムに関連する情報を記憶するためのストア(store：記憶装置)と、共通な共用ライブラリとを使用するファイルシステム内に保存された情報に関するリクエスト（要求）を取り扱うためのファイルマネージャである。このファイルマネージャは、ファイルシステムの内部実行(internal implementation)に何ら影響を与えることなくマルチプルパブリック・インターフェースを供給できるように、ファイルシステムへの外部インターフェースを内部実行から分離するための手段を提供する。また、外部インターフェースに明らかな影響を与えることなく複合実行（マルチ処理）（multiple implementation）がサポートされるように、個別のファイルシステムの実行をパブリックインターフェースから分離する手段を提供する。更に、個別のファイルシステムを実行するために必要な労力を低減する手段を提供する。
一実施例によると、ファイルシステム内のすべてのデータは、属性(attribute)またはフォーク(forks)の２種類の構成の内、どちらか一方の構成で保存される。
一実施例によると、属性とは、ボリューム、ディレクトリ、ファイル、フォーク、またはファイルクラス(file class)と言った特定のシステムユニットに関連する記述的なデータである。このような記述的情報のすべては、実際にそれがどのように保存されているかに関わらず、属性としてアクセスされる。従って、名前、特権(privilege)、ファイルのタイプおよびクリエータ(creator)、フォーク長のバイト数などは、すべて属性としてアクセスすることができる。ある属性の解釈が定義されてもよく、また個別のファイルシステムは、どの属性がどの種類のオブジェクトに関連づけることができるかについて制限を加えてもよい。
属性は、例えば、作者、文書のタイプ、ユニットのサイズ、ユニットに関連するキーワード等、ユニットにアクセスする他のソフトウエアにとって都合が良いと思われる、ユニットについての情報を提供する。属性は、ユニットをオープンしたりアクセスしたりすることなく、ソフトウエアに提供される。一実施例によると、属性は、必要に応じてプログラマーが定義することができる。特に、属性は、その属性を創造した（または、属性が添付されたものを所有する）プログラム以外のソフトウエアによってアクセスされる必要性のある、小さなデータアイテムを保存するのに使用される。属性は、そのファイルシステムにおけるいかなる固有の構成(persistent structure)、例えば、ボリューム、ファイルクラス、ディレクトリ、ファイル、そして、フォーク等、にも関連づけることができる。そして、それぞれの構造に関連する非常に多くの属性が存在する可能性があると仮定される。
特定の属性は、識別子によって識別される。一実施例では、これはOSTypeとして知られる４文字コードでもよい。また、１組の識別子を使用しても良い。第１の識別子は、属性を所有するサービスを識別する。一実施例によると、例えば、「fmgr」はファイルマネージャ属性に使用され、「fndr」はファインダ属性に使用され、「hfs」はＨＦＳボリューム特定の属性に、アプリケーション記号はアプリケーションが生成した属性として使用される。第２の識別子は、同サービスが所有する異なる属性を見分けるために使用される。属性の値は、固定最大サイズ（ＡＰＩは勧めるが、小さい値を必要としない）を持たない、解釈されない１以上のバイト数（ゼロ長の属性をサポートする必要は無い）の列である。属性値は、関連するタイプを持たない。属性の名前を知る者はだれでも、値のフォーマットを知っていると仮定される。与えられた属性が２以上のフォーマットで値を持つことができる場合、開発者は、これを取り扱うための独自のプロトコルの開発を自由に行うことができる。
一実施例によると、属性は、システムによって保持されているファイルマネージャ内のすべての情報へのアクセスを提供するために使用される。オペレレーティングシステムが、そのファイルシステムにおける固有な構成について知っている全て、フォークデータ以外は、属性を介してアクセスすることができる。これは、他の手段を介してもアクセスすることができるファイルの名前や、フォークの長さなどの情報を含む。他の実施例では、サービス名「fork」を定義し、このフォーク名を属性名の第２のOSTypeとして利用することにより、フォークデータにもアクセスできるようにする。
フォーク(forks)とは、順序よく並べられたバイトの列で、入力および出力が実行される基本的なデータ単位である。フォークは、そのフォークを創造したソフトウエアに主にアクセスされる、大きなデータアイテムを保存するために用いられる。フォークはファイルにのみ関連づけられ、それぞれのファイルについて相対的に少ない数のフォークが存在すると仮定される。一実施例によると、フォークのデータは０バイトから２の63乗のバイト長であり、間を空けてメモリ内に割当てられている。
一実施例によると、ファイル内のフォークは、１つのOSTypeによって識別することができる。フォーク内のデータは、間を空けてアロケートしてもよい。フォークのフォーマットを定義するそれぞれのフォークに関連するOSTypeがある（標準ＨＦＳボリュームでは、これはリソースフォークとして「rsrc」にデフォルトし、データフォークとしてファイルのタイプにデフォルトする）。同時アクセスに対するすべての特権の制限は、フォークレベルで制御される。すべてのフォークは、ＩＤとそのデータを持つ。
一実施例によると、アプリケーションファイルは１つのフォーク、すなわち、ダイアログボックスや、メニューなどの構成を含むリソースフォークを有しても良い。データファイルは、テキストデータを含むデータフォークのみを有することができる。本発明の一実施例によると、２つ以上のフォークを定義することができる。他のフォークは、そのファイルを作成したソフトウエアが使用できる情報を含んでも良い。例えば、言語処理プログラムにより、タイプされたとおりに文書を第２言語に翻訳し、文書の２つのバージョンを２つの異なるフォークに保存することができる。フォーク自身の存在をユーザは知らないかもしれないが、言語処理プログラムは、文書のどのバージョンをリトリーブするためにどのフォークにアクセスするかを知っている。マルチプルフォークの他の使用については、本発明の開示を理解することにより、通常の技術を有する者により変更可能である。
一実施例では、フォーク内のデータは、オープンパスを介してアクセスされる。パスはある特定のフォークのために作り出されたランタイム・コンストラクト(runtime constructs)であり、特定のアクセス方法を使用するように定義される。与えられたフォークについて１以上のパスを作ることができ、異なるパスは異なるアクセス方法を使用することができる。しかし、先に作り出されたパスは、後で作り出されたパスを利用してできることについて制限を加えることができる。
一実施例では、ファイルとは、ファイルシステム内でコピーし、移動し、削除し、微細な改名をすることができるフォークと属性の集合である。全てのファイルは名前（文字列）と、ペアレントディレクトリとしての役割を持つ１つのディレクトリと、そのデータが保存されている特定のボリュームを持つ。ファイルは、ボリューム内で唯一である値によって特定することができる。
一実施例によると、ファイルは任意の数のフォークを持ち、ファイル内のそれぞれのフォークは４バイトコードで見分けられる。すべてのファイルは、名前、タイプコード、クリエータコード、および一連の特権を持つ。
一実施例によると、ファイルは、ユニットとして容易に取り扱うことのできる情報の最大集合体を表す。ファイルの目的は、ユーザーの経験が情報の微細な集まりの概念を構築できる基礎を提供することである。プログラム内のファイルマネージャＡＰＩを介してより細かい情報にアクセスし、扱うことができるので、その目的は、ユーザーやコーラがファイルを総括的に取り扱うことのできるユニットとして見ることである。
一実施例によると、ファイルクラスは、同タイプやクリエータまたは両方を共用するボリューム内のファイルの論理グループである。あるファイルシステムの動作は、ファイルクラスに関連している。
一実施例によると、ディレクトリとは、ファイルとディレクトリの集合である。すべてのディレクトリは、名前（文字列）と、そのペアレントディレクトリとしての役割を持つ１つのディレクトリと、そのデータが保存されている特定のボリュームとを持つ。ディレクトリは他のディレクトリを含むことができるので、ボリューム上のファイルを含むディレクトリの階層が存在することがある。ディレクトリは、ボリューム中で唯一である値によって識別することもできる。
一実施例によると、ディレクトリの目的は、ファイルを探し出して使用するためのコンテクストを提供することである。ファイルは、関連ファイルをグループにまとめ、ファイル名を解釈するための多少のコンテクストを提供するために用いることのできる、ディレクトリのコンテクストで表現することができる。
一実施例によると、ファイルマネージャによって管理され、特殊な特徴を持った一つのスペシャルディレクトリがある。ファイルシステムのどれかのエンティティから始めて（どのファイル、ディレクトリ、またはボリュームでも良い）、そのエンティティのペアレントディレクトリに移り、更にそのペアレントディレクトリのペアレントディレクトリに移るというようにすると、最終的にメタルートディレクトリ(meta-root directory)に達する。このメタルートディレクトリはペアレントディレクトリを持たないが、非直接的には自分以外のファイルシステム内のもののペアレントである。メタルートはボリューム上には存在しないが、ファイルマネージャによって作り出され、ファイルマネージャ自身によって維持される。一実施例によると、ファイルマネージャがボリュームをマウントする度に（以下参照）、そのボリュームのルートディレクトリがメタルートをそのペアレントとして持つようにマウントする。メタルートは実際にはボリューム上にストアされないので、ファイルマネージャは、コーラがメタルート内またはそれを用いてできることについて厳しく制限している。制限された（拡張できない）一連の属性のみをメタルート上で扱うことができ、ファイルとディレクトリはメタルート上で作成することはできない。
ボリュームも、ファイルとディレクトリの集合である。すべてのボリュームは名前（文字列）を持っており、いくつかの形式の記憶媒体（ローカルなものまたは遠隔にあるもの）に関連している。ボリュームはファイルマネージャが使用できるユニット（単位）として機能する。一実施例によると、ボリュームは、ユニットとして利用可能にしたり利用不可能にされたファイルおよびディレクトリの最小集合体である。１つの脱着可能なディスクや、ディスクドライブのパーティション、またはディスクのセットなどのユニットは、ボリュームとして定義することができる。なお、ボリュームの内容をコンピュータが利用することができるが、その時点のユーザがデータに実際にアクセスすることを許可されない場合もある。
一実施例によると、すべてのボリュームは、他のディレクトリやファイルを含むことができ、ルートディレクトリとして知られる、少なくとも１つのディレクトリを持つ。そのボリューム中のすべてのエンティティについて、もしペアレントディレクトリと、そのペアレントディレクトリのペアレントディレクトリと言ったようにディレクトリを見つけることができるとすれば、そのボリュームのルートディレクトリに最終的に必ず到達することができる。現時点では、ボリュームがファイルマネージャによってマウントされたときはいつでも、そのボリュームのルートのペアレントディレクトリをメタルート(meta-root0として設定する。
一実施例によると、ファイルマネージャのすべてのリクエストは、そのシステムの何人かのユーザまたはユーザのグループに代わって行われる。ファイルマネージャに関する限り、このようなユーザまたはユーザのグループは、それに固有な値（アイデンティティとして知られている）によって識別される。
一実施例によると、アクセス方法とは、フォーク中のデータがパスを介してアクセスすることのできるモデルのことである。一実施例によると、２つのアクセス方法が定義される。１つはフォーク上のさまざまな量のデータにランダムアクセスすることができるストリームであり、もう１つは、フォーク内に構成された記録の挿入、削除、および検索をすることができるBTreeである。
図１は、本発明に係るソフトウエアを実行することができる模範的なコンピュータを示すブロック図である。コンピュータ１０は、処理部（ＣＰＵ）１２、外部記憶装置１４、ディスク記憶装置１６、入出力（Ｉ／Ｏ）制御部１８、少なくとも一つの入力装置２０、少なくとも一つの出力装置２２、ランダムアクセスメモリ（ＲＡＭ）２４、および上記それぞれの構成要素に接続する共通システムバス２６を持つ。コンピュータ１０は、バス２６およびＩ／Ｏ制御部１８を介して入力および出力装置２０および２２に接続する。更に、コンピュータ１０は、ネットワーク２７と通信することも可能である。
コンピュータ１０は処理部１２によって実行される多数のソフトウエアの部分を含む。これらのソフトウエアの部分の一つが、オペレーションシステム２８である。一実施例において、オペレーションシステム２８は、マルチプルアドレス空間を維持することができるマイクロカーネル(microkernel)オペレーションシステムである。ファイルマネージャ３０は、オペレーションシステム中に内在する。模範的な実施例では、本発明のコンピュータ１０は、カリフォルニア州のCupertinoにあるアップルコンピュータ社によって作られたアップルマッキントッシュ（TM）コンピュータシステムであり、ファイルマネージャ３０を含むマイクロカーネルオペレーションシステムを内包するマイクロプロセッサおよびメモりを持つ。コンピュータの構成部分は、本発明の開示を理解することにより、通常の技術者の技術範囲で変更することが可能である。本発明はマッキントッシュ環境で記述されたものであるが、本発明の精神の範囲内および通常の技術を持った技術者がDOS，Unix、または他のコンピュータ環境で実施できるものも本発明に含まれる。
一実施例によると、本発明はマイクロカーネル構造をしたオペレーションシステムの一部であり、カーネルは以下のサービスを提供するものとする。カーネルは、すべてのファイルシステムの共用データ構成をファイルシステムのコードが存在するすべてのアドレス空間へマッピングすることができる、アドレス空間管理に向けられている。これは、すべてのコードおよびデータを単一のアドレスルームへマッピングすることによって提供することができる。また、カーネルは、タスク創作およびタスク終了の告知、セマフォ同期機構およびメッセージの送り先となることのできる複数のオブジェクトを供給するメッセージシステムを提供すると良い。このメッセージシステムにより、クリエータ定義値をそれぞれのオブジェクトに関連させたり、複数のオブジェクトを同じポートにマッピングしたり、メッセージをポートから受け取ったり、適切なタイプのメッセージがそのポートに送られたときにコールされる機能を持ったり、メッセージの受信者がそのメッセージが元々どのオブジェクトに向けて送信されたものかを決定したり、そのオブジェクトのクリエータの定義値を導き出したりすることができる。そのようなマイクロカーネル機構の一例は、アップルマッキントッシュ（TM）コンピュータで使用されるNuKERNEL（TM）によって提供されている。このNuKERNEL（TM）システムは、１９９３年９月３０日出願の係属中の米国特許出願番号第０８／１２８，７０６号記載の「コンピュータに於ける仮想メモリの分散バッキングストア制御のためのシステム（System For Decentralizing Backing Store Control Of Virtual Memory In A Computer）」、１９９４年３月３０日出願の米国特許出願番号第０８／２２０，０４３号記載の「オブジェクト指向のメッセージ渡しシステムおよび方法（Object Oriented Message Passing System And Method）」、および本出願の日前後にＴｈｏｍａｓ Ｅ． ＳａｕｌｐａｕｇｈおよびＳｔｅｖｅｎ Ｊ． Ｓｚｙｍａｎｓｋｉの名で出願された「オブジェクト指向のメッセージフィルタリングのシステムおよび方法（System and Method Of Object Oriented Message Filtering）」に記述されている。これらの３つの特許出願は、参照により本願に包含されるものとする。
メッセージシステムによると、サービスはサーバによって提供され、サービスを使用したいソフトウエアは、サーバのクライアントと呼ばれる。メッセージは、クライアントによって目的地（宛先）へ送信され、サーバによって受信される。メッセージは、クライアントに代わってサーバが機能を実行するようにし向ける。メッセージオブジェクトは、メッセージシステムクライアントへのさまざまなリソースを示す、アブストラクトエンティティである。これらのオブジェクトは、例えば、サーバによって管理されるボリュームや、フォークや、ファイルを表しても良い。クライアントは、オブジェクトにメッセージを送り、オブジェクトはObjectID（オブジェクトＩＤ）によって識別される。
メッセージポートは、サービスを表すアブストラクト・エンティティである。これらのポートは、例えば、装置のドライバ、ファイルマネージャ、またはウィンドウマネージャを示しても良い。サーバは、ポートからメッセージを受け取り、そのポートはポートＩＤ（PortID）によって識別される。オブジェクトはポートに割り振られている。オブジェクトに送られたメッセージは、オブジェクトのポートから受信される。ポートおよびオブジェクトは、サーバの代わりにメッセージシステムによって作成される。オブジェクトを作成するために、オブジェクトに向けて送られたメッセージがリトリーブされる（取出される）ポートを指定しなければならない。本発明の一実施例において、オブジェクトおよびポートはファイルマネージャのさまざまな構成部分間の通信を確立するために使用される。
本発明の一実施例は、カーネル同期サービスを利用して、重要な(critical)セクションや、論理メモりをアロケートするカーネルメモリ管理サービスや、複数の実行スレッドを提供するカーネルタスクサービスを保護するために使われる、セマフォに対するサポートを提供する。
本発明の一実施例に係るファイルマネージャ３０の機構の概略ブロック図を図２に示す。一実施例によると、ファイルマネージャは、インターフェースモジュール３１０と、ディスパッチャ（またはディスパッチモジュール）３００と、ストア（記憶装置）３４０と、共用ライブラリ３３０と、フォーマットエージェントモジュール３２０とを含む、それぞれ個別にロードすることができるモジュールの集合として見ることができる。
インターフェースモジュール＃１、＃２など（３１０）は、システムの他のモジュールへの異なるパブリックインターフェースを示す。そのような２つのインターフェースモジュールを図２に示すが、このようなモジュールをいくつ提供しても良い。特定の環境のために書かれたソフトウエアは、その環境下において標準のインターフェースを使用することができる。これらのインターフェースモジュール３１０は、それらのインターフェースを介して得られたリクエストをメッセージ構成に翻訳し、それらのメッセージをディスパッチャ３００へ送信することにより、呼び出し(calling)ソフトウエアとオペレーションシステム、特にファイルマネージャとの間のインターフェースを行う。
ストア３４０は、それぞれのフォーマットエージェントを識別するための識別子と、ディスパッチャポートに割り当てられたオブジェクトを識別するための識別子と、フォーマットエージェント識別子とオブジェクト識別子間のマッピングをするためのマッピング情報とを保存する記憶構成を含む。一実施例によると、ストア３４０は、ディスパッチャ３００の概念的な部分である。ディスパッチャ３００は、インターフェースモジュール３１０からメッセージを受信し、ストア３４０に含まれるマッピング情報を用いて、どのフォーマットエージェントがリクエストを満足することができるかを決定する。その後、メッセージを適切なフォーマットエージェント＃１、＃２など（３２０）へと転送する。３つのフォーマットエージェント＃１、＃２、＃３が図示されているが、含まれるフォーマットエージェントの数はいくつでも良い。一実施例によると、それぞれのフォーマットエージェントは、特定のファイルシステムフォーマットに関連する記憶媒体にアクセスすることができる。
適切なフォーマットエージェント３２０は、ディスパッチャ３００からメッセージを受信し、リクエストを処理することによって、オペレーションシステム、特にファイルマネージャと、アクセス中の記憶媒体間のインターフェースを行う。リクエストが完了すると、フォーマットエージェント３２０は、元のコーラへ戻るのに必要な情報をディスパッチャ３００へ応答する。リクエストを実行するのに関わったフォーマットエージェント３２０のすべてが終了し、ディスパッチャ３００への返答を終えると、ディスパッチャ３００はリクエストを初期化するのに用いたインターフェースモジュール３１０に返答し、コーラへ戻る必要のある情報を送る。インターフェースモジュール３１０は、その情報をインターフェースに適した形態に翻訳し、それをコーラに戻す。
フォーマットエージェント３２０の内部メカニズムの部分は、異なるモジュール間で似ているため、本発明に係るファイルマネージャは、すべてのフォーマットエージェント３２０が使用できる共用ライブラリ３３０を含んでもよい。このライブラリは、フォーマットエージェント３２０間で共用することができる共通のメカニズムの実施を含むため、これらのモジュールの開発が容易になる。共用ライブラリ３３０は、エージェントがストア３４０を形成する記憶構成を構築できるようにするために、フォーマットエージェント３２０が必要とするソフトウエアルーチンをも含む。
一実施例によると、一インターフェースモジュールは、本発明に係るファイルマネージャとファイルマネージャＡＰＩの過去の実施にインターフェースし、他のインターフェースモジュールは現在のオペレーションシステムと本発明に係るファイルマネージャ間のインターフェースを供給する。他のインターフェースモジュールは、本発明の開示を理解することにより通常の技術者の技術範囲内で提供することが可能である。
一実施例によると、図３に示すようにストア３４０は複数の制御ブロックを持つ。制御ブロックは、エージェント制御ブロック（エージェントＣ．Ｂ．）３４１０と、ボリューム制御ブロック（ボリュームＣ．Ｂ．）３４２０と、ファイル制御ブロック（ファイルＣ．Ｂ．）３４３０と、フォーク制御ブロック（フォークＣ．Ｂ．）３４４０と、パス制御ブロック（パスＣ．Ｂ．）３４５０と、イタレータ制御ブロック（イタレータＣ．Ｂ．）３４６０とを含む。
本発明の一実施例に係るファイルマネージャは、それが管理するファイルシステムエンティティ（例えば、ボリュームフォーマット、ボリューム、ファイル、フォーク、パス、イタレータ(iterators)）のランタイム状態を維持するために、これらのファイルシステムのエンティティーに関する頻繁にアクセスされる情報のコピーをメモリ内に維持するために、メモリに保存された制御ブロック構成を使用する。加えて、これらの制御ブロックのそれぞれは、リクエスト処理タスク（ＲＰＴｓ）の活動を調整するために使用されるセマフォを含む。
一実施例によると、これらの制御ブロックは、以下のように保存される。エージェント制御ブロック３４１０のリストがあり、リスト上のエージェント制御ブロックのそれぞれは、フォーマットエージェント３２０に対応する。それぞれのエージェント制御ブロック３４１０は、そのフォーマットを有するボリュームのためのボリューム制御ブロック３４２０のリストをもつことができる。ボリューム制御ブロック３４２０のそれぞれは、オープンのフォークを持つファイルのためのファイル制御ブロック３４３０のリストと、そのボリュームの何かを現在示しているイタレータのためのイタレータ制御ブロック３４６０とを有することもできる。それぞれのファイル制御ブロック３４３０は、そのファイルのためにオープンされたフォークのためのフォーク制御ブロック３４４０のリストを持つことができる。フォーク制御ブロック３４４０のそれぞれは、そのファイルのためにオープンされたそれぞれのアクセスパスのためのパス制御ブロック３４５０を持つことができる。
それぞれの制御ブロックは、タイプに関わらず、いくつかの共通フィールドを持つヘッダ３４００を有する。それらのフィールドは、制御ブロックタイプ、バージョン、ペアレント制御ブロックポインタ、リストリンク、セマフォ、エージェント制御ブロックポインタ、およびエージェント特定データポインタである。この構成を図３ｂに示す。制御ブロックタイプフィールドは、制御ブロック（ボリューム、ファイルなど）のタイプである。バージョンフィールドは、使用された制御ブロック構成のバージョンである。ペアレント制御ブロックポインタフィールドは、これのペアレントである制御ブロックへのポインタである。例えば、ファイル制御ブロック３４３０にとって、このフィールドはそのフィールドをリスト中に有するボリューム制御ブロックへのポインタである。リストリンクフィールドは、同じペアレントを持つ前後の制御ブロックへのポインタである。セマフォフィールドは、制御ブロックへのアクセスを調整するために使用されるセマフォである。エージェント制御ブロックポインタフィールドは、その構成を所有するエージェント制御ブロックポインタへのポインタである（つまり、もしペアレントポインタをたどり続ければ、最終的にはこのポインタにたどり着く）。エージェント特定データポインタフィールドは、制御ブロックへのエージェント特定拡張へのポインタである。このフィールドは、ファイルマネージャの異なる実行が制御ブロックに含まれる、あるパブリックフィールドを定義するので、またすべてのボリュームフォーマットがフォーマットに特有のデータおよび状態の変遷を追うために追加のプライベートフィールドを必要とすると思われるので、含まれている。制御ブロックサービスモジュール３３５０（図４）は、フォーマットエージェント３２０がこれらの追加フィールドを保持するために、制御ブロックを追加のルーム（メモリ空間）にアロケートすることができるようにする。そして、エージェント特定データポインタは、この追加されたメモリ空間へのポインタである。制御ブロック内に含まれるフィールドの定義は、本発明の開示を理解することにより、当業者により変更可能である。
エージェント制御ブロック３４１０の一実施例は、図３ｃに示す構成をし、以下のフィールドを含む。即ち、制御ブロックヘッダ、ボリュームリストヘッダ、エージェントオブジェクトＩＤ、エージェントサイン（エージェント署名）、タイムアウト（時間切れ）ベースである。制御ブロックヘッダは、図３ｂに示す上記のフィールドを含む。ボリュームリストヘッダは、このボリュームフォーマットについてのボリュームのリストへのポインタである。エージェントObjectIDは、このボリュームフォーマットのためにフォーマットエージェントへメッセージが送られる先のObjectIDである。エージェントのサイン（署名）は、ボリュームフォーマットの個別の識別子である。タイムアウトベースは、このボリュームフォーマットのためにリクエストがかける時間を見積もるための基準として使用される時間の長さである。従って、使用可能なタイムアウトの長さである。
図４は、本発明の一実施例に係る共用ライブラリ３３０のブロック図である。共用ライブラリ３３０は、５つの論理コードモジュールを含む。それらは、レンジロックサービスモジュール３３１０と、BTreeサービスモジュール３３２０と、キャッシュサービスモジュール２２５と、ブロック入出力（Ｉ／Ｏ）サービスモジュール３３４０と、制御ブロックサービスモジュール３３５０である。
レンジロックサービスモジュール３３１０は、レンジロック機能を提供するために使用されるすべてのフォーマットエージェントのための標準メカニズムを提供するものである。エージェントがこのメカニズムを使用するか、個別に供するかを決定するのは、まだ、それぞれのフォーマットエージェントによる。この決定は、以下により詳しく説明する。BTreeサービスモジュール３３２０は、フォーマットエージェントが使用することのできる共通BTreeコードを含む。一実施例に係る機構により、同じコードを内部およびパブリックBTreeインターフェースの両方をサポートするために使用することができる。キャッシュサービスモジュール３３３０は、ファイルマネージャ・キャッシュの管理を行うものである。それは、キャッシュ記憶をアロケートして保持し、どのようにさまざまなキャッシュブロックが使用されているかについてのデータベースを維持している。一実施例によると、この構成により、大量のキャッシュを有してもキャッシュヒットを速く行うことができるようにし、さまざまなサイズのバッファを扱い、リード・拡張処理をサポートする。ブロックＩ／Ｏサービスモジュール３３４０は、ドライバの入出力を行うために、ディスクベースのフォーマットエージェントに共通インターフェースを提供する。
制御ブロックサービスモジュール３３５０は、本発明に係るファイルマネージャによって内部的に使用されるさまざまな種類の制御ブロックをアロケートし、アクセスし、取り扱い、リリースするコードを含む。制御ブロックサービスモジュール３３５０は、すべての重要(critical)セクションが保護されるように、実行される複数のスレッドに於けるリクエストの同時処理を可能にするサービスを提供している。特に、同じデータを使用する実行の複数のスレッドが存在する場合、お互いにそのデータを変更しないような方法が必要とされる。
一実施例によると、これは、制御ブロックを獲得し、それをリリースすることによって達成される。例えば、ボリュームから情報を読み出す場合（ただし変更を加えない）、ボリュームの制御ブロックは、同時にほかの人も読み出せるように共用アクセスのために獲得され、アクセスが終了するとリリースされる。または、アクセスパスについての情報を更新するために、１つのスレッドのみがある時に排他的にアクセスできるように、パスの制御ブロックがその排他的アクセスだけのために獲得される。第１のスレッドが排他的アクセスのための制御ブロックを獲得している間に、実行される第２のスレッドがアクセスしようとした場合、その第２のスレッドは、第１のスレッドが、その制御ブロックをリリースするまで強制的に待たされることになるこのようにして、種々のスレッドが互いに強調して実行されることになる。一実施例によると、これらの構成のために実際のデータは、カーネルバンド内にアロケートされ、グローバルに参照されるが、これらを取り扱うコードはそれらがすべてのフォーマットエージェント３２０にアクセスできるように共用ライブラリに含まれている。
図５ａは、本発明の一実施例に係るディスパッチャ３００のブロック図である。ディスパッチャ３００は、２つのタスクモジュールを含む。ディスパッチメインテナンスモジュール３０４０と、要求処理モジュール３０３０である。またディスパッチャ３００は、ディスパッチストア３０５０と、ディスパッチメッセージポート３０１０とを含む。ボリューム制御ブロックオブジェクト３４２５と、パスオブジェクト３４４５と、イタレータオブジェクト３４６５は、上記のディスパッチメッセージポート３０１０に割り振られている。ディスパッチメッセージポート３０１０は、ボリュームまたはパス、またはイタレータを指示していない要求を受信するファイルマネージャオブジェクト(FMO)３０２０も含む。
一実施例によると、ディスパッチ・メインテナンスモジュール３０４０は、ファイルマネージャの初期化、シャットダウン、カーネルメッセージの取り扱いや要求のキャンセルや要求処理タスク数の保全およびキャッシュのフラッシュなどの定期的な保全作業などを含む保全動作の１つの実行するスレッドからなる。他のメインテナンスの手順は、他の実施例において、本発明の開示を理解することにより当業者によって実施可能であろう。
一実施例によると、要求処理モジュール３０３０は、ディスパッチャに送られたファイルマネージャ要求を実際に処理するために使われる要求処理タスク（ＲＰＴ）として知られる、複数のスレッドの実行からなる。どの時点においても、これらのタスクのそれぞれは、要求の処理か、または、ファイルマネージャポートに入力される新たなメッセージを待つことである。新しい要求メッセージが入力される度に、メッセージシステムは、ウェイティングしている次のＲＰＴにそれを渡す。
一実施例によると、ＲＰＴの経過を追うために、ディスパッチャ３００は、各実行中のＲＰＴにつき１つずつの、RequestTaskState構造のセットを含むディスパッチストア３０５０を維持している。一実施例において、これらの構造は二重にリンクするリスト中で維持される。この構造は、タスク識別子、現在処理中（もし処理中であれば）の要求のメッセージ識別子、そして要求が転送されるフォーマットエージェント（もしあれば）の経過を追う。
一実施例において、この構成は図５ｂに示すフォーマットを持ち、リストリンクと、タスクＩＤと、フラグと、ターミネーションアクションと、現在のメッセージと、キャンセルされたメッセージと、エージェント制御ブロックポインタとを含む。リストリンクフィールドは、RequestTaskState構造の前後へのポインターである。フラグフィールドは、ＲＰＴが現在要求を処理しているか、また、その要求がフォーマットエージェントへ送られたかどうかを示すために利用される。ターミネーションアクションフィールドは、一実施例によれば、ＲＰＴが予期せず終了した場合に呼び出されるメインテナンスタスクのために割り込みをするソフトウエアである。現在のメッセージフィールドは、ＲＰＴが現在処理しているメッセージのメッセージＩＤである。もしＲＰＴが現在要求を処理しているのでなければ、現在のメッセージフィールドは、ある知られた値にリセットされる。キャンセルされたメッセージフィールドは、キャンセルされたものであれば、そのメッセージのメッセージＩＤである。エージェント制御ブロックポインタは、要求が転送された先のフォーマットエージェントのための制御ブロックへのポインタである。
一実施例によれば、ディスパッチャ３００は、以下の付加的なグローバルを含む。すなわち、RequestTaskQueueはRequestTaskState構造のリストへのヘッダであり、AgentControlBlockListはエージェント制御ブロックのリストへのヘッダであり、FileManagerPortはファイルマネージャポートＦＭＯ３０２０であり、FileManagerObjIDは、ファイルマネージャ要求のための通常のObjectIDであり、RequestTaskCountは実行中のＲＰＴの数であり、RequestTaskDesireは与えられた時間に実行させるＲＰＴの望ましい数であり、MasterSemaphoreは、エージェント制御ブロックのリストへのアクセスを調整して使用するために用いられるセマフォである。
図６は、本発明の一実施例に於ける、インターフェースモジュールがコーラからの要求をプロセスする工程を示すフローチャートである。要求は、指定された入力および出力パラメータと共にコールの形態でコーラから受信される。ステップ６１０において、インターフェースモジュールは、コールのいずれかの入力パラメータを解釈する。出力パラメータに書き込みするために入力パラメータが必要かどうが判断される（ステップ６２０）。もしインターフェースモジュールがそのコールに対する出力パラメータに書き込むための十分なデータを持っている場合、ステップ６２０の判断はｎｏとなり、出力パラメータはステップ６２５で書き込みがされる。
出力パラメータに書き込みするのにメッセージが必要とされた場合、インターフェースモジュールは出力パラメータを得るために、送信する必要のある第１メッセージを決定する（ステップ６３０）。メッセージは、ディスパッチャ３００へ送信される（ステップ６４０）。ディスパッチャ３００から応答を受信すると、インターフェースモジュールによって解釈される（ステップ６５０）。応答されたデータは、ステップ６６０で一時バッファに格納される。これにより、インターフェースモジュールは、コールが出力パラメータとして返される値を手に入れるために多くのメッセージを必要とする状況および、コールが多くのメッセージからの応答データによって決定される値を有する１つの出力パラメータを持つと言った状況を扱うことができる。ステップ６７０では、コールが完了したかどうか、つまり、すべての必要なメッセージが出力パラメータ値を決定するために送信されたかどうかを判断し、コールを遂行するために必要なすべてのアクションを実行する。もし完了していなければ、インターフェースモジュールは送信すべき次のメッセージを決定し（ステップ６７５）、ステップ６４０へ戻る。そうであれば、出力パラメータが一時バッファから書き込まれ（ステップ６８０）、インターフェースモジュールはコーラに戻る（ステップ６９０）。
一実施例において、この処理はステートマシーンとして実施される。そのようなステートマシーンにとって、インターフェースモジュールへのコールの目的は、情報を集めたり、ファイルシステム上で動作を行ったり、または両方を行うことであるとみなすことができる。従って、ステートは、集められた情報の特定のセットや、実行する必要のない動作（その動作がすでに実施されたかまたはコールへ提供された入力パラメータに基づいて実行する必要が無い場合のどちらか）の特定のセットを表す。同様に、トランジションは、更なる情報を集め、更なる動作を行い、または両方を行うためにディスパッチャに送るべきメッセージを表す。インターレースモジュールは、入力パラメータによって示されたすべての情報が収集され、入力パラメータによって示されたすべてのアクションが完了するまでステートマシーンの実行を続ける。
一実施例によると、要求は同時に処理される。しかし、それぞれのボリュームは、単に一つのものであり、制御ブロックの１階層しか存在しない。従って、ボリュームおよび制御ブロックは、アクセスをＲＰＴ間で対等でなければならない共用リソースである。一実施例では、これは、それぞれの制御ブロックにセマフォを含め、制御ブロックと、制御ブロックが表すファイルシステム内のデータへのアクセスを対等にするためにこれらのセマフォを使用することにより実現することができる。
一実施例によると、この対等にするためのポリシーは、
１） エージェント制御ブロックを追加または削除するために、ディスパッチャのためのマスターセマフォおよび追加または削除される制御ブロックのためのセマフォが、排他的アクセスのために獲得されなければならない。
２） エージェント制御ブロックのセットをトラバースするために、ディスパッチャのためのマスターセマフォおよび現在のエージェントのための制御ブロックのためのセマフォが、共用アクセスのために獲得されなければならない。
３） ボリュームが現在マウントされているかどうかを変更するために、ボリュームの制御ブロックのためのセマフォおよびボリュームのエージェント制御ブロックのためのセマフォが、排他的アクセスのために獲得されなければならない。
４） ボリューム制御ブロックのセットをトラバースするために、ディスパッチャのためのマスターセマフォおよび現在のボリュームに関するエージェント制御ブロックセマフォが、共用アクセスのために獲得されなければならない。
５） ファイル、フォーク或はパス制御ブロックを追加または削除する特定のボリュームのための制御ブロック階層の構造を変更するために、ボリューム制御ブロックのセマフォおよび追加または削除される制御ブロックのためのセマフォが、排他的アクセスのために獲得されなければならない。
６） ある特定のボリューム（そのボリュームの下でのファイル、フォークおよびパス制御ブロックすべて）のための制御ブロック階層の構成をトラバースするかまたは、そのボリュームのためのメタデータ（ディスク上の共用構造、例えば、ディスクアロケーションマップ）を変更するために、ボリューム制御ブロックのセマフォが、排他的アクセスのために獲得されなければならない。
７） ファイル、フォークまたはパスについての情報を読み出すために、適切な制御ブロックのセマフォが、共用アクセスのために獲得されなければならない。
８） ファイル、フォークまたはパスについての情報を更新するために、適切な制御ブロックのセマフォが、排他的アクセスのために獲得されなければならない。
９） 複数のセマフォはマスタ、パス、フォーク、ファイル、ボリューム、ボリュームフォーマットの順番に従って獲得されなければならず、この逆の順番で解放されなければならない。
フォーマットエージェント処理
図７ａ乃至７ｆは、フォーマットエージェントがストア３４０を形成する制御ブロックを作成する、本発明の一実施例に係る処理を示すフローチャートである。図７乃至７ｆでは制御ブロック構成は図３に示す構成を参照している。エージェントがどのようにしてそのフォーマットで構成された記憶媒体にアクセスするか、などの残りの機能は、エージェント毎に異なったものとなる。本発明の開示を理解することにより当業者はそうした機能を実現することが可能であろう。
図７ａは、マウント要求に応じてボリューム制御ブロックがストア３４０で作成される、本発明の一実施例に係る処理を示している。最初に、ボリューム制御ブロックがプライベートフィールドのルーム（メモリ空間）で作成される（ステップ７１００）。ボリューム制御ブロックのプライベートおよびパブリックフィールドは、ステップ７１１０で書き込みがされる。一実施例では、プライベートフィールドはフォーマットエージェントにのみ知られており、一方パブリックフィールドはファイルマネージャにより要求されるフィールドである。排他的アクセスのためにエージェント制御ブロックセマフォが獲得され（ステップ７１２０）、ボリューム制御ブロックはエージェント制御ブロックのボリュームリストにリンクされる（ステップ７１３０）。そして、エージェントセマフォが解放され（ステップ７１４０）、フォーマットエージェントはディスパッチャへ戻る。
図７ｂ，７ｃは、オープン要求に応じてパス制御ブロックがストア３４０に作成される、本発明の一実施例に係る処理を示している。最初に、パス制御ブロックがプライベートフィールドに対するルームに割り当てられる（ステップ７２０９）。パス制御ブロックのプライベートおよびパブリックフィールドは書込みがされる（ステップ７２０５）。
ステップ７２１０では現存のフォークに対するフォーク制御ブロックが存在するかどうかが判定される。フォーク制御ブロックが既に存在している場合は、排他的アクセスのためにファイルが存在しているボリュームに対するボリューム制御ブロックセマフォが獲得される（ステップ７２１１）。パス制御ブロックはフォーク制御ブロックのパスリストにリンクされ（ステップ７２１２）、ボリューム制御ブロックセマフォは解放される（ステップ７２１３）。そして処理は終了する。
ステップ７２１０でフォーク制御ブロックが存在していない場合は、フォーク制御ブロックがプライベートフィールドに対するルームに割り当てられる（ステップ７２１５）。フォーク制御ブロックのプライベートおよびパブリックフィールドは書き込みがされ（ステップ７２２０）、パス制御ブロックはフォーク制御ブロックのパスリストにリンクされる（ステップ７２２５）。
図７ｃを参照すると、処理されているファイルに対するファイル制御ブロックが存在するかどうかが判定される（ステップ７２３０）。ファイル制御ブロックが存在する場合は、排他的アクセスのためにボリューム制御ブロックセマフォが獲得される（ステップ７２３１）。フォーク制御ブロックはファイル制御ブロックのパスリストにリンクされ（ステップ７２３２）、ボリューム制御ブロックセマフォが解放される（ステップ７２３３）。そして処理は終了する。ステップ７２３０で現在のファイルに対するファイル制御ブロックが存在しない場合は、ファイル制御ブロックがプライベートフィールドに対するルームに割り当てられる（ステップ７２３５）。ファイル制御ブロックのプライベートおよびパブリックフィールドは書き込みがされ（ステップ７２４０）、フォーク制御ブロックはファイル制御ブロックのフォークリストにリンクされる（ステップ７２４５）。排他的アクセスのためにボリューム制御ブロックセマフォが獲得される（ステップ７２５０）。ファイル制御ブロックはボリューム制御ブロックのファイルリストにリンクされ（ステップ７２５５）、ボリューム制御ブロックセマフォは解放される（ステップ７２６０）。そして処理は終了する。
図７ｄおよび７ｅは、クローズ要求に応じてパス制御ブロックがストア３４０から排除される、本発明の一実施例に係る処理を示している。排他的アクセスのためにボリューム制御ブロックセマフォが獲得される（ステップ７３００）。ステップ７３０５で、パス制御ブロック内のデータはフラッシュされる（つまり、パス制御ブロック内のデータは記憶媒体に書込まれる）。パス制御ブロックはフォーク制御ブロックのパスリストからリンク解除（リンクされなくなる）される（ステップ７３１０）。ステップ７２３０では、このフォークに対するパス制御ブロックがそれ以上あるかどうかが判定される。他にパス制御ブロックが存在する場合は、ボリューム制御ブロックセマフォは解放され（ステップ７３３２）、それら他のパス制御ブロックがオープンの状態のままであるようにし、そして処理は終了する。
ステップ７３３０で他にパス制御ブロックが存在しない場合は、階層のバックアップをする必要がある（図３参照）。従って、データはフォーク制御ブロックにフラッシュされ（ステップ７３３５）、フォーク制御ブロックはファイル制御ブロックのファイルリストからリンク解除される（ステップ７３３０）。
ステップ７３４５（図７ｅ）では処理されているファイルに対するさらに他のフォーク制御ブロックが存在するかどうかが判定される。他のフォーク制御ブロックが存在する場合は、ボリューム制御ブロックセマフォが解放され（ステップ７３４７）、他のホーク制御ブロックがオープンの状態のままであるようにし、そして処理は終了する。ステップ７３４５で他にフォーク制御ブロックが存在しない場合は、階層のバックアップをする必要がある（図３参照）。従って、データはファイル制御ブロックにフラッシュされ（ステップ７３５０）、ファイル制御ブロックはボリューム制御ブロックのファイルリストからリンク解除され（ステップ７３３５）、ボリューム制御ブロックセマフォが解放される（ステップ７３６０）。そして処理は終了する。
図７ｆは、本発明の一実施例に係る、アンマウント要求に応じてボリューム制御ブロックがストア３４０から削除される処理を示している。最初に、共用アクセスを行うためにボリューム制御ブロックセマフォが獲得される（ステップ７４００）。さらに、そのボリュームに対する新たな要求がブロックされる。一実施例では、これはメッセージングシステムにより提供されるロックオブジェクトフィーチャを使用して行われる。ステップ７４１０では、このボリュームに対するファイル制御ブロックが存在するかどうかが判定される。ファイル制御ブロックが存在する場合は、ボリューム制御ブロックセマフォが解放され（ステップ７４１５）、処理は失敗となる。ファイル制御ブロックが存在しない場合は、データがボリューム制御ブロックからフラッシュされる（ステップ７４２０）。ステップ７４３０では、このボリュームに対するイタレータ（反復）制御ブロックが存在するかどうかが判定される。存在する場合は、各イタレータはエンティティを何も参照しないようにリセットされる（ステップ７４１５）。一実施例では、これはアンマウントされているボリュームを制御するフォーマットエージェントへメッセージを送ることにより達成される。このボリュームに対するイタレータ制御ブロックが存在しない場合、そしてステップ７４３５の後は、ボリューム制御ブロックセマフォが解放され、排他的に再獲得される（ステップ７４４０）。排他的アクセスのためにエージェント制御ブロックセマフォが獲得される（７４５０）。ボリューム制御ブロックはエージェント制御ブロックのボリュームリストからリンク解除される（ステップ７４６０）。エージェント制御ブロックセマフォは解放され（ステップ７４７０）、処理は終了する。
フォーマットエージェント３２０の目的はディスパッチャ３００からの要求を受信し、それらを処理し、そして要求の結果を応答する。一実施例では、上述のように、フォーマットエージェント３２０は共用ライブラリ３３０を利用して、いくつかのフォーマットで共通の動作を行う。いくつかの要求は制御ブロックのパブリックまたはプライベートフィールドのいずれかに格納されている情報を使用して実行可能であるが、一方、媒体の読み出し／書き込み、あるいはボリュームのデータを得るのに用いたデバイスへのアクセスを必要とするような要求もある。
一実施例では、ボリュームがブロック用のデバイスに格納されている場合は、フォーマットエージェント３２０は共用ライブラリ３３０のブロック入出力サービスモジュール３３４０を使用して媒体のデータを読み出したり書き込んだりすることができる。フォーマットエージェント３２０が、あるデータが繰り返し使用可能であると予測したり、またファイルマネージャにそのデータに対しバッファを割り当てさせようとする場合は、共用ライブラリ３３０のキャッシュサービスモジュール３３３０を使用することができる。エージェント３２０が、共用ライブラリ３３０のBTreeサービスモジュール３３２０によって扱うことのできるフォーマットを持つBTreeへのアクセスを必要とする場合は、そのモジュールを使用することができる。
一実施例では、共用ライブラリ３３０のこれら３つのモジュールは互いに依存している。BTreeサービスモジュール３３２０は必要とするデータに対するバッファを得るためにキャッシュサービスモジュール３３３０をコールすることができる。キャッシュサービスモジュール３３３０は実際にキャッシュにおいてデータを読み書きするためにブロックI/O（入出力）サービスモジュール３３４０をコールすることができる。
しかし、これらのモジュールを連結しないことが望ましい。従って、他の実施例では、これらのモジュールはフォーマットエージェント３２０をコールバックしてこれらの必要を満たしている。フォーマットエージェント３２０は、フォーマットエージェント３２０が共用ライブラリ３３０上で行うコールに応じて共用ライブラリのモジュールが使用することができる手続きインタフェースを有している。これらのコールのためのインタフェースは、BTreeサービスモジュール３３２０がキャッシュサービスモジュール３３３０に対して行う必要のあるコールとキャッシュサービスモジュール３３３０がブロックI/Oサービスモジュール３３４０に対して行う必要のあるコールに対し同一の機能性を提供する。
この実施例によると、フォーマットエージェント３２０が共用ライブラリ３３０のBTreeサービスモジュール３３２０をコールすると、BTreeサービスモジュール３３２０は、そのキャッシュ動作のためにフォーマットエージェント３２０をコールする。するとフォーマットエージェント３２０はキャッシュサービスモジュール３３３０をコールしてこれらのコールを実行することを選択するか、または他の何らかのメカニズム（例えばプライベートキャッシュまたはキャッシュ使用しない直接の読み書き）を使用することができる。同様に、フォーマットエージェント３２０が共用ライブラリ３４０のキャッシュサービスモジュール３３３０をコールすると、そのキャッシュはそのブロックのI/O動作のためにフォーマットエージェント３２０をコールする。再び、フォーマットエージェント３２０はブロックI/O動作をコールしてこれらのコールを実行することを選択するか、または他の何らかのメカニズム（例えばネットワークドライバへのコールまたはラムディスクバッファの読み出し）を使用することができる。
ディスパッチャによる要求処理
ディスパッチャ３００の主な機能は、要求を正しいフォーマットエージェント３２０へ送ることである。どのようにこれを行うかは要求のタイプに依存しているが、大抵のケースを網羅する一般的な規則は以下の如くである。
１）要求が特定のボリューム、ディレクトリ、ファイルまたはフォークに向けられている場合、そのボリューム、ディレクトリ、ファイルまたはフォークに対するスペシフィケーションの一部はエンティティが存在するボリュームに対するボリュームObjectIDである。メッセージはそのObjectIDへ送られる。そのOjbectIDには適切なボリューム制御ブロックを指すポインタが関連付けられている。ディスパッチャはそのポインタを獲得し、その制御ブロックから、エージェント制御ブロックポインタを使用して、フォーマットエージェントに対するObjectIDを有するエージェント制御ブロックへ到達する。そしてメッセージを、そのフォーマットエージェントへ送る。こうした種類の要求にはFileCreate（ファイル生成）、Delete（削除）、PathOpen（パスオープン）、VolumeFlush（ボリュームフラッシュ）が含まれる。
２）要求が特定のアクセスパスまたはイタレータへ向けられている場合は、メッセージはそのアクセスパスまたはイタレータに対するObjectIDへ送られる。そのOjbectIDには適切なパス制御ブロックまたはイタレータ制御ブロックを指すポインタが関連付けられている。ディスパッチャはそのポインタを獲得し、その制御ブロックから、エージェント制御ブロックポインタを使用して、そのフォーマットエージェントに対するObjectIDを有するエージェント制御ブロックへ到達する。そしてメッセージをフォーマットエージェントへ送る。こうした種類の要求にはRead（読出し）、Write（書込み）、Access Pathsに対するClose（クローズ９、Iteratorsに対するIterateが含まれる。
３）要求が１つ以上のボリュームを含む（そして、それゆえに１つ以上のボリュームフォーマットと１つ以上のフォーマットエージェントを含む可能性がある）場合、メッセージはファイルマネージャのオブジェクトのObjectIDへと向けられる。ディスパッチャは要求を分割して各々１つのフォーマットエージェントしか含まないパーツにして、それらのメッセージをそれぞれ適切なフォーマットエージェントへと送る。例えば、FileCopy（ファイルコピー）要求は存在するファイルと作成されるべき新しいファイルのスペシフィケーションを含んでいる。これらのスペシフィケーションは含まれているボリュームに対するVolumeObjectIDを含んでいる。そこから、フォーマットエージェントに対するObjectIDが得られる（上記ケース１参照）。ディスパッチャは存在するファイルを有しているフォーマットエージェントへRead（読出し）要求を送り、新しいファイルを有しているフォーマットエージェントへWrite（書込み）要求を送る。こうした種類の要求にはFileCopyRename（ファイルコピー改名付）やFileMoveRename（ファイルムーブ改名付）が含まれる。
４）要求が固有のファイルシステム構造を含んでおらず、しかしその代わり内部ファイルマネージャデータを含んでいる場合は、その要求はファイルマネージャのオブジェクトのobjectIDへ送られ、ディスパッチャはいずれのフォーマットエージェントへも送ることなくその要求を分解することができる。この種類の要求にはSetCurrentDirectory（現デイレクトリの設定）やGetFileManagerVersion（ファイルマネージャのバージョン情報取得）が含まれる。
ほとんどの種類の要求は先の４つのカテゴリへに入る。しかしながら、特殊なケースであって特殊な規則で扱われる２つの要求MountとPathNameResolveがある。こうした種類の全ての要求はファイルマネージャオブジェクトのObjectIDへ送られる。
５a）マウンティングの前にはボリュームのフォーマットは不明であり、従ってまだマウント要求を特定のフォーマットエージェントへ向けることができない。その代わりに、ディスパッチャはそのボリュームをマウント可能かどうか尋ねるメッセージを各フォーマットエージェントへ送る。ディスパッチャは「イエス」と応えるフォーマットエージェントを選択してマウントメッセージを送る。
５b）ファイルマネージャを実現する多くには、間接的であるためエンティティが存在するボリュームのVolumeObjectIDを含まない可能性のあるボリューム、ディレクトリまたはファイルを特定する方法を有している。一実施例では、これには部分的または関連するパスネーム・スペシフィケーション（ベースエンティティを特定し、ファイルシステムを巡回して目標へ到達するような１スペシフィケーション）を提供することが含まれている。これを分解するために、ディスパッチャは部分パスネームを分析（parse）して、この情報を使用してエンティティに対する適切なスペシフィケーションを決定しなければならない。ディスパッチャはフォーマットエージェントへ要求を送ってパスに含まれているエンティティの親ディレクトリを決定して、それらがボリューム上のルートディレクトリであるかどうかを判定する必要がある。
図８ａ乃至８ｍは、本発明の一実施例に係るディスパッチャ処理を示すフローチャートである。
図８ａはディスパッチャ３００が新たなエージェントをインストールする処理を示している。エージェント制御ブロックがプライベートフィールドのためのルームで作成される（ステップ８０００）。エージェント制御ブロックのプライベートおよびパブリックフィールドに書き込みがなされる（ステップ８０１０）。排他的アクセスのためにマスターセマフォが獲得される（ステップ８０２０）。エージェント制御ブロックはディスパッチャのエージェントのリストにリンクされる（ステップ８０３０）。そしてマスターセマフォは解放される（ステップ８０４０）。
図８ｂは、本発明の一実施例に係る、ディスパッチャ３００による要求処理手順を示している。ルーチンの開始時点で、ディスパッチメッセージポート３０１０内の次の要求がディスパッチャ３００によりリトリーブされる（ステップ８１０１）。要求タスクステート・ストラクチャ３０５０が処理されている要求に対して書き込まれ、そのストラクチャのフラグフィールドが、ストラクチャがビジーであり要求が現在処理されていることを示すようにセットされる。ステップ８１０４では、このタイプの要求がボリュームオブジェクトへ送られるものであるかどうかが判定される。このテスト（および後続のテスト８１０６、８１０８、８１５０、８１５１、８１５２および８１５３）は要求が正しいタイプのオブジェクトへ送られたかどうか決定するエラーチェッキングキャパビリティ（不図示）を含んでいる。そうでない場合は、適切なエラーメッセージが作成される。要求がボリュームオブジェクトへ送られるタイプではない場合は、要求がパスオブジェクトへ送られるタイプであるかどうかが判定される（ステップ８１０６）。そうでない場合は、要求がイタレータオブジェクトへ送られるタイプであるかどうかが判定される（ステップ８１０８）。そうでない場合は、要求がマルチプルボリューム要求のタイプであるかどうかが判定される（図８ｃ、ステップ８１５０）。そうでない場合は、要求がディスパッチャ単独で扱われるタイプであるかどうかが判定される（ステップ８１５１）。そうでない場合は、要求がマウント要求であるかどうかが判定される（ステップ８１５２）。そうでない場合は、要求がパスネーム分解(resolve)要求であるかどうかが判定される（ステップ８１５３）。そうでない場合は、ディスパッチャは「不明要求」エラーで応答する（ステップ８１５４）。ディスパッチャは図８ｂのＣへループして、要求タスクステートフラグを、要求が処理されていないことを示すアンビジーにセットし（ステップ８１００）、ディスパッチポートから次の要求を得る（ステップ８１０１）。
ステップ８１５０、８１５１、８１５２および８１５３における判定はメッセージ自体の内容に基づくものである。これらのメッセージはファイルマネージャオブジェクトFMO３０２０でディスパッチャ３００に受信される。
ステップ８１０４で要求がボリュームオブジェクトへ送られるタイプである場合は、ルーチンは図８ｄのステップ８１１０へ進む。ステップ８１１０では、ボリュームオブジェクトからのボリューム制御ブロックポインタがリトリーブされる。エージェント制御ブロックポインタはボリューム制御ブロックからリトリーブされる（ステップ８１１１）。ステップ８１１２では、要求に対して共通の前処理が行われる。この前処理には、メッセージが処理される前に実行可能であり、かつボリュームフォーマットの個々の実現にかかわらず同じ方法で行われる、つまりファイルシステムフォーマットから独立している、何らかの動作が含まれている。一実施例では、これにはメッセージ内の少数のフィールドの有効性の検証、メッセージ構造のトレーラ（追跡）パートのフィールドの書き込み、およびコーラまたはインタフェースモジュールに提供された何らかの大容量バッファの現在のアドレス空間へのマッピングが含まれている。
ステップ８１１３では、エージェント制御ブロック内のObjectIDを使用して要求が適切なフォーマットエージェントへ送られる。これには要求タスクステート構造３０５０において送られたフラグを、要求が送られたことを示すようにセットすることが含まれる。ステップ８１１４では、その要求に対して共通の後処理動作が行われる。この後処理には、要求が処理された後で実行可能であり、かつボリュームフォーマットの個々の実現にかかわらず同じ方法で行われる、つまりファイルシステムフォーマットから独立している、何らかの動作が含まれている。これには前処理ステップ８１１２で行われた、いずれかのマッピングのクリーンアップ、連続的にメッセージを処理した結果として生じたいずれかのイベントをポストすること、およびファイルマネージャの性能に関する統計要素（スタティスティクス）を収集することが含まれる。
ステップ８１１５では、その要求がうまく処理されたかかどうかが判定される。そうである場合は、ディスパッチャはその要求に対し適切なイベントを作成する。これらを検出し扱うイベントマネージャは、またイベントは上記の参照した出願中である「オペレーティングシステムのイベント情報の分配方法および装置」に記載されている。その要求がうまく処理されない場合は、ディスパッチャはフォーマットエージェントから受信した応答を使用して発信元のインタフェースモジュールへ応答を送る。そしてルーチンは図８ｂのＣへループする。
ステップ８１０６で、その要求がパスオブジェクトへ送られるタイプである場合は、ルーチンは図８ｅのステップ８１２０へ進む。ステップ８１２０では、ボリューム制御ブロックポインタがパスオブジェクトからリトリーブされる。エージェント制御ブロックポインタがパス制御ブロックからリトリーブされる（ステップ８１２２）。ステップ８１２２〜８１２７は上述の図８ｄのステップ８１１２〜８１１７と同じであるので、ここで説明は繰り返さないこととする。
ステップ８１０８で要求がイタレータオブジェクトへ送られるタイプである場合は、ルーチンは図８ｆのステップ８１３０へ進む。ボリューム制御ブロックポインタがイタレータオブジェクトからリトリーブされ（ステップ８１３０）、エージェント制御ブロックポインタがイタレータ制御ブロックからリトリーブされる（ステップ８１３１）。ステップ８１３２では、その要求に対して共通の前処理動作が行われ、その要求はステップ８１１２、８１１３でそれぞれ上述したようにエージェントへ送られる（ステップ８１３３）。
ステップ８１３５では、イタレータを異なるボリュームへ移動する必要があるかどうかが判定される。そうである場合は、共用アクセスのためにマスタおよびエージェント制御ブロックセマフォが獲得され（ステップ８１３６）、イタレータ制御ブロックは新たなボリューム制御ブロックへ移動される（ステップ８１３７）。一実施例では、これは最初にイタレータが移動される前に指していたボリュームを制御するフォーマットエージェントにメッセージを送り、ついでイタレータが移動された後で指しているボリュームを制御するエージェントにメッセージを送ることにより達成される。そしてマスターセマフォが開放され（ステップ８１３８）、ステップ８１３３で要求が送られる。ステップ８１３５でイタレータを移動する必要がない場合は、ディスパッチャは図８ｄのステップ８１１４〜８１１７とそれぞれ同じである、図８ｇのステップ８１３９〜８１４２を実行する。
ステップ８１５０で、その要求がマルチプルボリューム要求である場合は、ルーチンは図８ｈのステップ８１６０へ進む。ディスパッチャに受信されたメッセージに基づいて要求により影響される複数のボリュームが決定される（ステップ８１６０）。それらのボリュームに対するボリューム制御ブロックを指すポインタがリトリーブされ（ステップ８１６１）、それらのボリューム制御ブロックに対するエージェント制御ブロックを指すポインタがリトリーブされる（ステップ８１６２）。
ステップ８１６３では、それらのボリュームへアクセスするよう要求されてりるフォーマットエージェントが同じであるかどうかが判定される。そうである場合は、ステップ８１１２〜８１１７にそれぞれ対応するステップ８１６４〜８１６９が実行される。
エージェントが同じでない場合は、処理は図８ｉのステップ８１７０へ進む。ステップ８１７０で共通の前処理動作が行われる。ある要求が第１のボリュームに対して作成され（ステップ８１７１）、その要求は第１のボリュームに対するフォーマットエージェントへ送られ（ステップ８１７２）、ある要求が第２のボリュームに対して作成され（ステップ８１７３）、その要求が第２のボリュームに対するフォーマットエージェントへ送られる（ステップ８１７４）。ステップ８１７５では、その要求が完全かどうかが判定される。そうでない場合は、ルーチンはステップ８１７１へループする。要求が完全である場合は、ステップ８１６５〜８１６９に対応するステップ８１７６〜８１８０が実行される。
ステップ８１５１で、その要求がディスパッチャに単独で扱われるタイプである場合は、処理は図８ｊのステップ８１８１へ進む。特にある要求については、ディスパッチャはエージェントからの応答を受信することなく、その要求を扱うのに十分な情報を入手することができる。この場合、前処理動作が行われ（ステップ８１８１）、メッセージに対する応答が作成される（ステップ８１８２）。図８ｄのステップ８１１４〜８１１７に対応するステップ８１８３〜８１８６が実行される。
ステップ８１５２で、その要求がマウント要求である場合は、ルーチンは図８ｋのステップ８１９０へ進む。ステップ８１９０で共通の前処理動作が行われ、「マウント可能か」というメッセージが作成され（ステップ８１９１）フォーマットエージェントへ送られる。ステップ８１９２では、メッセージが第１のフォーマットエージェントへ送られる。ステップ８１９３では、フォーマットエージェントがボリュームをマウントできるかどうかが判定される。そうでない場合は、最後のメッセージが送られてからエージェントのリストが変更されたかどうかが判定される（ステップ８１９４）。このテストは、ディスパッチャがその要求を処理している間に、あるエージェントが削除または付加された場合に生ずる可能性がある、希な状況を扱うものである。ステップ８１９３の判定が肯定である場合、ルーチンはステップ８１９２へループバックして再びポーリングを開始する。そうでない場合は、ルーチンはステップ８１９５へループしてメッセージを次のエージェントへ送る。
ステップ８１９３でエージェントがボリュームをマウント可能であった場合は、ステップ８１９７が実行される。図８ｄのステップ８１１３〜８１１７はステップ８１９７〜８２０１に対応する。
ステップ８１５３で、その要求が分解(resolve)パスネーム要求である場合は、ルーチンは図８ｍのステップ８２１０へ進む。ステップ８２１０では共通の前処理動作が行われる。分解パスネームの場合は、ディスパッチャによって、アクセスされているボリュームに対して不完全で部分的なスペシフィケーションが受信される。ディスパッチャは、その部分的なスペシフィケーションからボリュームを決定する（ステップ８２１１）。エージェント制御ブロックがボリューム制御ブロックからリトリーブされ（ステップ８２１２）、その要求がエージェント制御ブロック内のObjectIDを使用してそのエージェントへ送られる（ステップ８２１３）。ステップ８２１５では、エージェントがスペシフィケーションを分解するのに成功して、そのボリュームに対して有効なスペシフィケーションを作成したかどうかが判定される。そうでない場合は、フォーマットエージェントからの応答で返されたスペシフィケーションから決定されるパス内の次のボリュームを処理するために、ルーチンはステップ８２１１へループする。スペシフィケーションがエージェントによって十分に分解された場合は、図８ｄのステップ８１１４〜８１１７に対応するステップ８２１５〜８２１８が実行される。
メッセージ構造
本発明の一実施例によれば、メッセージはインタフェースモジュールとディスパッチャ間、ディスパッチャとフォーマットエージェント間で通信を行うのに使用される。メッセージは処理されている要求に応じて変化する所定の構造を使用して作成される。この構造の定義に関する一実施例は付録(Appendix)Ａ（「FSRequests.h」）で提供されている。さらに、いくつかの構造を以下に説明する。付録Ｂ（「FSTypes.h」）には、付録Ａに記載のメッセージ構造で使用されている定数とタイプの定義が含まれている。
定義
次の説明ではメッセージ構造で使用されているいくつかのオブジェクトとコンセプトに関する定義を挙げることにする。これらの定義は説明の目的で提供され、本発明の開示を理解すれば当業者であれば変更することが可能であろう。
FSSpecificationは特定のボリューム、ファイル、またはディレクトリのスペシフィケーションである。FSSpecificationはボリュームID、ディレクトリIDおよびネーム（名称）を含んでいる。１つの例外を除くと、特定のボリューム、ファイル、またはディレクトリを必要とする全てのファイルマネージャ要求は、正確にこの形式（パスネームが入らない）でFSSpecificationを参照する。この１つの例外とは、FSSpecificationの有効性要求に従わない処理に対するスペシフィケーションを受け入れるResolvePathname要求である。
FSIteratorは、オブジェクト上、特にボリューム、ファイルおよびディレクトリ上を反復（イタレート：iterate）するためのメカニズムである。FSIteratorはいずれのボリューム、ファイルまたはディレクトリにも位置することが可能で、そして現在参照しているいずれの親オブジェクト、次の兄弟オブジェクト、先の兄弟オブジェクト、第一の子供オブジェクト、次の子供のオブジェクトにも再度位置することが可能な構成である。またFSIteratorは現在参照しているオブジェクトに対するFSSpecificationを含んでおり、FSIteratorを必要とするいずれのコール（要求元）へも送ることが可能である。
FSIteratorはより精巧なFSSpecificationとして使用することができ、そこではポインタFSIteratorはFSSpecification構造を記述するのに用いられるが、ポインタの実際の価値は、ポインタが指すエンティティ間の関係に基づいてファイルシステム内を移動することができるという事実から生じている。その最も簡潔な形式で、ポインタは、現在指しているエンティティといくらかの関係があるファイルシステム内で、最初および／または最後のエンティティへと移動することができる。従って、あるディレクトリを指定しているFSIteratorが与えられると、それは現在のディレクトリを親ディレクトリとして有する最初／最後のファイルまたはディレクトリを指定するよう移動することができる。同様に、FSIteratorはある他のエンティティと同じ関係を持つ、前後のエンティティを指定するよう移動することができる。こうして、あるファイルまたはディレクトリを指定しているFSIteratorが与えられると、それは同じ親ディレクトリを有する次／先のファイルまたはディレクトリを指定するよう移動することができる。
ファイルシステム内でFSIteratorを段階的に移動することはしばしば極めて有益であるが、より強力なFSIteratorのコールは、単一のコールでFSIteratorを移動のパターン内を移動させ、処理に際して通過する各エンティティからの情報を（属性の形式で）収集するのに使用することができる。こうして、単一のコールで、同じ親ディレクトリを有する全てのファイルから属性を収集するのにFSIteratorを使用することができる。
アイデンティティはファイルマネージャ特権の主題（サブジェクト）である。アイデンティティは個別、または個々のアイデンティティのセット又は別々のセットとなり得る。アイデンティティは特定ファイルおよびディレクトリ上の特定動作を行う許可を与えられる。
特権はアイデンティティがファイルまたはディレクトリに対して何をすることができるかを特定するものである。各ファイル及びディレクトリは、アイデンティティのリストや、そのアイデンティティに関連した特権を持っている。PrivilegeIteratorはファイルまたはディレクトリに対するアイデンティティ／特権ペア上で反復するメカニズムである。全てのボリューム、ディレクトリおよびファイルは、PrivilegeIteratorに関するリストを有し、これは、そのボリューム、ディレクトリまたはファイル上のどんな要求が特定のアイデンティティに代わって実行を許可されているかを規定している。これらのアクセス制御リストは、ファイルシステムに対するアイデンティティに許可されている特権を規定する。
APIは、コーラが常に１度にいくつかの属性値をグループで獲得し、セットしていると想定している。単一の属性を獲得してセットするのは退化したケースである。コーラが属性のグループを識別して獲得またはセットするよう要求される際はいつでも、BufferDescriptor（データを保持するためのもの）、そして転送される属性と、データが格納された、あるいはこれから格納されるバッファの位置の両方を特定するFSAttributeDescriptor列を指すポインタを提供することが求められる。
コーラが標準ストリームI/Oアクセス方法を使用してアクセスパスをオープンすると、その作成されたアクセスパスで実行される動作の種類と、その新たなパスがオープンしたままである場合に他のアクセスパスで実行が許可される動作の種類とを記述するAccessConstraint構造を提供するよう求められる。他のアクセス方法はこの構造あるいは、これと同等の構造を使用することができる。また、時にはアクセス方法自身によってアクセス制限が示される。
要求（リクエスト）
このセクションでは本発明の一実施例に基づく全ての要求を説明する。一実施例では、これらの要求の全ては同期及び非同期の形式を有している。
ファイルシステム・エンティティ要求
次の要求はFSSpecificationsによって識別可能なエンティティを操作(manipulate)するのに使用される。すなわちファイル、ディレクトリ、そしてボリュームである。FileCreateは新たなファイルを作成し、DirectoryCreateは新たなディレクトリを作成するものである。AttributesGet、AttributesSet、AttributesGetSizeはファイル、ディレクトリおよびボリュームに関連していた属性を操作するのに使用される。FileFlushはメモリにバッファされているファイルに関する全ての情報を、そのファイルが存在するボリューム上に強制的に書き出すのに使用される。これにはその属性、格納割り当て等の全てのメタ情報が含まれている。TestEntityは、FSSpecificationとFSSearchCriteriaを受けて、スペシフィケーションにより参照されるものが基準に合うかどうかについてのブーリアン(boolean)表現を返す。EntityTypeは、FSSpecificationによって参照されているものの種類（ファイル、ディレクトリまたはボリューム）と、それがシステムに対しある特別な重要性を持つことを示すいくつかのフラグを単に返す。
ボリューム要求
次の要求はボリュームを操作するのに使用される。VolumeMountは、既知のデバイス上のボリュームをマウントするための通常の要求である。先にマウントされたボリュームは、VolumeRemount要求を使用して再度マウントすることができる。VolumeRemountを使用するには、コーラはまずVolumeGetRemountDataをコールし、再マウントを行うのに必要な情報を収集させなければならず、VolumeGetRemoutSizeを使用して、VolumeGetRemountDataが返すデータのサイズを得なけらればならない。このVolumeRemountはデバイスに対するボリュームの関係を想定するため特に有用である。
ボリュームは、通常ボリュームの全情報をファイルマネージャから削除するVolumeUnmount要求を使用してアンマウントされる。VolumeEjectは同様の要求であるが、デバイスをシステムから排除させるものでもある。VolumeOffilineは、ファイルマネージャがボリュームの存在（その上のファイルはオープンの状態のままである、等）を記憶しているという点でわずかに異なっているが、しかしファイルマネージャは、ある期間利用不可能なボリュームに対して準備をする。オフラインのボリュームがアクセスされる場合、ファイルマネージャはボリュームを再び利用可能にしようと試みる。
VolumeFlushは、メモリにバッファされているあるボリュームに関する全てのメタ情報（ディレクトリ構造等）を、そのボリュームが存在するデバイスへ強制的に書き出すのに使用される。VolumeCreateは、デバイスに空のボリュームを作成する(initialize)のに使用される。VolumeGetCapabilityは、ある特定のボリュームがサポートすることができる要求を知るのに使用される。
フォーク要求
次の要求はファイル内のフォークを操作するのに使用される。ForkCreateはファイルにフォークを付加するのに使用され、ForkDeleteはフォークを削除するのに使用される。ForkAttributesGet、ForkAttributesSet、ForkAttributesGetSizeはフォークに関連した属性を操作するのに使用される。最後に、ForkFlushはメモリにバッファされているフォークからの全ての情報を、そのフォークが存在するボリュームへ強制的に書き出すのに使用される。
ファイルシステムイタレータ要求
次の要求は、ファイルシステム内のファイル、ディレクトリおよびボリューム上の情報を発見して収集するようにファイルシステムのイタレータを操作するのに使用される。FSIteratorCreateはイタレータを作成するのに使用され、FSIteratorDisposeは、１つのイタレータを処分(dispose)するのに使用される。Iterateは、ファイルシステムでFSIteratorを１度に１ステップ移動するのに使用される。Searchは、与えられた基準に適合するファイル、ディレクトリ、またはボリュームを探しながら、ステップのパターンを通じてFSIteratorを移動するのに使用される。AttributesGetBulkは、通過する各ファイル、ディレクトリ、またはボリュームに対する属性値のセットの値を収集しながら、ステップのパターンを通じてFSIteratorを移動するのに使用される。AttributesGetBulkFilteredも同様の要求であるが、与えられた基準に合うそれらエントリーから属性値を収集するだけである。
ストリームアクセス方法要求
次の要求は標準ストリームI/Oアクセス方法のために、アクセスパスをオープン、クローズおよびアクセスパスを用いるのに使用される。PathOpenはアクセスパスをオープンするのに使用され、PathCloseはアクセスパスをクローズするのに使用される。PathReadとPathWriteはフォークデータの部分を読み書きするのに使用される。
ストリームI/Oアクセス方法を使用してオープンされた各アクセスパスは、そのステートの中にフォークの現在の位置を含んでいる。そのためForkPositionDescriptorは、その位置に関連付けることができる。この現在位置は、PathReadおよびPathWriteによって読み出された、あるいは書き込まれたセクションの末尾に暗黙的にセットされるか、あるいはPathSetPositionコールを使用して明示的にセットされる。この位置の現在値は、PathGetPositionコールを使用して得ることができる。
コーラはストリームI/Oアクセス方法を使用してオープンしたいずれのフォーク内の範囲をロックすることも可能である。この範囲は排他的（どのオーバーラップする範囲もロックされないようにする）アクセスのために、あるいは共用（オーバーラップする範囲が排他的アクセスのためにロックされないようにする）アクセスのためにロックすることが可能である。PathLockRangeは、この範囲をロックするのに使用され、PathUnlockRangeは、その範囲のロックを解除するのに使用される。
最後の要求のいくつかは、そのフォークに割り当てられた記憶装置を操作するのに使用される。PathGetEOFはフォークの現在の長さをバイトで返し、PathSetEOFはその長さをセットする。EOFを通じてフォークに割り当てられたいずれの記憶内容は、フォークへの全てのアクセスパスがクローズされればただちに解放および再利用することができる。PathAllocateは記憶装置をフォークに割り当てるのに使用され、PathReleaseは記憶装置の割り当てを解除するのに使用される。これらの要求の両者とも範囲を決めるための引数を取り、これによりメモリ空間において間を空けて割り当てることができるファイルシステム上で、非連続的な割り当てを形成するのに使用することができる。PathWriteも、書き込みが割り当てられていない領域になされた場合に、そのフォークに記憶装置を割り当てるようにし、上述のように記憶装置はそのフォークへの全てのアクセスパスがクローズされた時に解放される。
バッキングストアアクセス方法要求
次の要求はメモリにマップファイルアクセス方法に関するアクセスパスを操作するのに使用される。BackingStoreCreateは、アクセスパスをオープンするのに使用され、BackingStoreDisposeは、アクセスパスをクローズするのに使用される。メモリマップアクセスパスは、メモリの読み出しおよび書き込みによって、そしてオペレーティングシステムのカーネルメモリマネージャに対する要求によって操作されるため、メモリマップアクセスパスを使用するための要求は存在しない。
ファイルクラス要求
次の要求はボリュームに対するファイルクラス情報を操作するのに使用される。FileClassAttributesGet、FileClassAttributesSet、およびFileClassAttributesGetSizeは、ファイルクラスに関連した属性にアクセスするのに使用される。FileClassIteratorCreateは、ボリュームに知られている全てのファイルクラスを移動できるイタレータを作成するのに使用され、FileClassIteratorDisposeはそのようなイタレータを処分するのに使用される。FileClassIterateは、イタレータを、ボリュームに知られているファイルクラスのリスト中を実際に移動するのに使用される。
特権要求
次の要求はファイル、ディレクトリ、およびファイルシステム内のボリュームに関連した特権を操作するのに使用される。PrivilegeGetは、アイデンティティが与えられると、そのアイデンティティが、与えられたファイルや、ディレクトリまたはボリュームに関して有している特権を返す、基本的な要求である。PrivilegeGetは、与えられたアイデンティティが、異なる特権を持つ可能性のあるグループのアイデンティティのメンバであるかどうか見るためにグループを評価することはしない。PrivilegeGetNativeは、ある特定のファイル、ディレクトリ、またはボリュームに対するアクセス制御リストの表現に依存するボリューム形式を得るのに使用される。そしてPrivilegeSetNativeは、そのデータを異なるファイル、ディレクトリまたはボリュームに適用するのに使用される。
PrivilegeIteratorCreateは、ある特定のファイル、ディレクトリまたはボリュームに対するアクセス制御リストを移動することが可能なイタレータを作成するのに使用される。そしてPrivilegeIteratorDisposeは、そのイタレータを処分する。PrivilegesIterateは、イタレータを１度に１ステップずつアクセス制御リストを通して移動するのに使用され、PrivilegeSearchはある特定のアイデンティティに合うエントリを探しながらイタレータをリストを通じて移動するのに使用される。あるイタレータが与えられると、PrivilegeAddは、新たなエントリをアクセス制御リストに挿入し、PrivilegeDeleteはエントリを削除し、PrivilegeChangeは現在のエントリを変更する。
その他の要求
次の要求はファイルマネージャ上でその他の動作を行うのに使用される。GetFileSystemVersionは、システム上で動いているファイルマネージャのバージョン数を返すものである。PathnameResolveは、関係するパスネームを取りそれを標準のFSSpecificationに分解する。FSDeleteはファイルまたはディレクトリを削除する。FSMoveRenameはファイルまたはディレクトリの親ディレクトリとネームを変更する。FSCopyRenameは、ファイルのコピーを作成し、その処理においてオプションで別の名前を付ける。
発明の利点
エンドユーザは本発明に係るファイルマネージャから少なくとも２つの大きな利益を得るであろう。第１は、全体のシステムで認識できる性能の向上である。同時実行可能によって、特にそれを利用するアプリケーションに関して、ファイルマネージャのスループットが向上する。そしてファイルマネージャをコールするバックグラウンド処理がフォアグラウンド性能に及ぼす影響はより小さいものとなる。
第２に、システム全体がより強固なものになる。本発明に係るファイルマネージャは、メッセージングシステムを利用してそのデータ構造を保護し、そのアプリケーションとシステム自体の間をより良く隔離させる。さらに、提供されたアーキテクチャ上の特徴によって、異なるファイルシステムや他のコードに対し、それらの機能性を提供するためにいくらかの危険をおかさなければならない、現在の必要性を排除することができる。
一実施例によれば、メッセージを使用してファイルマネージャ要求を作成するファイルマネージャに新たなインタフェースが提供される。このインタフェースは２つの点で有用である。第１には、それはトラップよりもメッセージングを使用するということ、第２には、要求の構造は従来のパラメータブロックに類似していないということである。メッセージプロトコルは、ファイルマネージャと通信を行うのに使用される本発明に従って規定される。共用ライブラリは、これらのメッセージをフォーマットしたり送ったり、また応答を扱う機能を持つ。メッセージインタフェースは、本発明に係るファイルマネージャによって、また他のシステムソフトウェアに関連したファイルマネージャによって内部的に使用されるサービスである。特に、本発明に係るファイルマネージャは、特定のディスクファイルシステムフォーマット／サーバプロトコルを実行するフォーマットエージェントと通信するのに、この同じインタフェースを使用する。
ファイルマネージャの一実施例によれば、Power PCマシン上のネイティブモードで動作することができる。この実施例によると、ファイルマネージャはアセンブリ言語コードをほとんど含まず、非RISCプロセッサ上で動作しているという想定を行うことがない。コードはバイトの順に依存せずに作成される。
ファイルマネージャの一実施例に基づきアクセスが解除される内部インタフェース／構造のほとんどは、本質的に危険なものである。従って本発明に係るファイルマネージャの利点の一つは、開発者の使用のために、これらのインタフェースをより安全なインタフェースに置き換えることである。こうして、本発明に係るファイルマネージャは、システムの利用可能な機能性を減少させることなく、むしろ、より安全に、そして他に動作しているソフトウェアに影響を及ぼすことなく使用できる再設計されたインタフェースを提供するものである。
本発明に係るファイルマネージャは、多数の異なるファイルシステム（現在と未来の）とのインターフェースを行い、これらの各ファイルシステムからの、合理的に可能な限り多くの機能性へのアクセスを提供するのに使用できる、高性能なアブストラクト・モデルを提供するよう設計されたファイルシステムモデルに基づいて構築される。
本発明の一実施例に係るファイルマネージャは同時性を提供する。既知のファイルマネージャの多くは１度に１つのファイルシステム要求しか処理することができない。ファイルシステム要求は、ファイルシステムに関するデータにアクセスする要求である。これは通常、特定のボリュームフォーマットに基づいて組織された記憶媒体上のデータへのアクセスを必要としている。先の要求が処理されている間に提出される他の要求は、キューに配列され後、１度に１つずつ処理される。これは特に後に控える要求が速度の遅い媒体に対するものである場合には煩わしいものである。
１度に１つのアプリケーションしか動作せず、一般に単一のフォアグラウンド・アプリケーションによってしかファイルマネージャ要求がされなかった初期のコンピュータシステムにおいては、このアプローチは合理的である。しかし、今日多くのコンピュータ上では、アプリケーションや初期化（起動）ルーチンなどが同時に動作する多くのサービスが存在しており、これらのサービスの多くはバックグラウンドでファイルマネージャ要求を発行する。フォアグラウンド・アプリケーション内で、いくつものタスクにファイルマネージャ要求を並行して発行することを許可する、NuKERNEL（TM）などのメッセージングシステムの出現によって、複雑性が増している。
これらの理由により、本発明に係るファイルマネージャは、１度に１つ以上の要求で同時発生する処理をサポートする。このサポートを達成するために、コードは完全に再エントリ可能であり、マルチタスキングを利用するものである。
従来のファイルマネージャは、初期の世代のパーソナルコンピュータの比較的単純な要求を扱うように設計されていた。しかし、それ以来市場価格が大幅に変化し、現在重要となっているが、当時は一時的な利点であったいくつかの特徴を実現するのが困難となっている。ディスクドライブははるかに大きくなり、競合するファイルシステムを搭載することがより重要であり、ネットワーキングは不可欠であり、そして先行技術のAPIは混乱して複雑である。
上述の特定の実施例の説明は本発明の一般的な特質を十分に明らかにしているため、他者が現在の知識を適用することにより、容易に変更が可能であり、そして／または、そうした特定の実施例を様々なアプリケーションに対して総括的な概念から離れることなく適用することが可能である。従って、そうした適用および変更は開示された実施例に対応する意味と範囲内で理解されるよう意図されるべきであり、またそのように意図されるものである。ここで使用される語句の表現は説明のためのものであり限定する目的で使用されているものではないことが理解されるであろう。

Claims (29)

1. 少なくとも１つのファイルシステムフォーマットの１つに従って構成された記憶媒体へのアクセスを要求するために適用される少なくとも１つのコーラを含むコンピュータにおいて、前記記憶媒体へのアクセス要求を処理するシステムであって、
   コーラからの要求を受取り、その要求をメッセージで出力するインターフェース手段と、
   前記ファイルシステムフォーマットに対応し、前記記憶媒体にアクセスするための要求を処理するフォーマットエージェント手段と、
   前記フォーマットエージェント手段を特定する少なくとも１つの第１の識別子と、ディスパッチポートに割り当てられた複数のオブジェクトを特定する第２の識別子と、前記第１と第２の識別子の間をマッピングするための情報をマッピングするマッピング情報を記憶する記憶手段と、
   前記インターフェース手段からの前記メッセージを受取るための前記ディスパッチポートを含み、前記マッピング情報に応答して前記フォーマットエージェント手段に前記メッセージを送出するディスパッチ手段とを有し、
   前記マッピング情報は複数の制御ブロックを有し、前記複数の制御ブロックは、少なくとも１つのエージェント制御ブロックと、前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのボリューム制御ブロックとを備えることを特徴とするシステム。
2. 前記オブジェクトは、前記インターフェース手段からのメッセージを受取るためのファイルマネージャ・オブジェクトを備え、前記ディスパッチ手段は、前記メッセージに含まれる情報に基づいて、前記ファイルマネージャオブジェクトからの前記メッセージを前記フォーマットエージェント手段に送出する手段を備えることを特徴とする請求項１に記載のシステム。
3. 前記複数の制御ブロックは更に、少なくとも１つのボリューム制御ブロックと少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのパス制御ブロックを更に備えることを特徴とする請求項１に記載のシステム。
4. 前記複数の制御ブロックは更に、少なくとも１つのボリューム制御ブロックと少なくとも１つのエージェント制御ブロックに接続された少なくとも１つの反復制御ブロックを備えることを特徴とする請求項１に記載のシステム。
5. 前記ディスパッチ手段は、前記メッセージの受信と送信を同時に行うための複数のスレッドを実行する手段を備えることを特徴とする請求項１に記載のシステム。
6. 前記ディスパッチ手段は更に前記システムのためのメンテナンス動作を実行するスレッドを備えることを特徴とする請求項１に記載のシステム。
7. ファイルマネージャを具備するコンピュータであって、
   前記ファイルマネージャは、
   少なくとも１つのファイルシステムフォーマットに従って構成されている記憶媒体へのアクセスを要求する少なくとも１つのコーラと、
   コーラからの要求を受信し、その要求をメッセージで出力する、前記ファイルマネージャの複数のインターフェースモジュールで実行されるインターフェース手段と、
   前記ファイルシステムフォーマットに対応し、前記記憶媒体にアクセスする要求を処理する、前記ファイルマネージャの少なくとも１つのフォーマットエージェントモジュールで実行されるフォーマットエージェント手段と、
   前記少なくとも１つのフォーマットエージェントモジュールを特定するための少なくとも１つの第１の識別子と、ディスパッチポートに割り当てられた複数のオブジェクトを特定する第２の識別子と、前記第１と第２の識別子をマッピングするためのマッピング情報を記憶する、前記ファイルマネージャの記憶モジュールで実行される記憶手段と、
   前記インターフェース手段から前記メッセージを受信するための前記ディスパッチポートを含み、前記マッピング情報に応答して前記少なくとも１つのフォーマットエージェントモジュールに前記メッセージを送信する、前記ファイルマネージャのディスパッチモジュールで実行されるディスパッチ手段とを有し、
   前記マッピング情報は複数の制御ブロックを有し、少なくとも１つのエージェント制御ブロックと、前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのボリューム制御ブロックと、前記少なくとも１つのボリューム制御ブロックと少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのパス制御ブロックと、前記少なくとも１つのボリューム制御ブロックと少なくとも１つのエージェント制御ブロックに接続された反復制御ブロックとを備えることを特徴とするコンピュータ。
8. 前記オブジェクトは前記インターフェース手段からメッセージを受信するファイルマネージャオブジェクトを有し、前記ディスパッチ手段は、前記メッセージに含まれる情報に基づいて、前記ファイルマネージャオブジェクトからの前記メッセージを前記フォーマットエージェント手段に送出することを特徴とする請求項７に記載のコンピュータ。
9. 前記ディスパッチ手段は、前記メッセージの受信と送信を同時に行うための複数のスレッドを実行する手段を備えることを特徴とする請求項８に記載のコンピュータ。
10. 前記ディスパッチ手段は更に前記システムのためのメンテナンス動作を実行するスレッドを備えることを特徴とする請求項８に記載のコンピュータ。
11. オペレーティング・システムと、少なくとも１つの記憶媒体と、前記少なくとも１つの記憶媒体へのアクセスを要求するコーラと前記オペレーティング・システムとの間をインターフェースするインターフェース手段と、前記オペレーティング・システムと前記記憶媒体との間をインターフェースし、各エージェントモジュールは少なくとも１つのファイルシステムフォーマットに対応している複数のエージェントモジュールと、前記少なくとも１つの記憶媒体へのアクセス要求を受取って処理するディスパッチャとを具備するコンピュータにおいて、
    前記ディスパッチャーは、
    少なくとも１つのエージェントモジュールを特定する少なくとも１つの第１の識別子と、要求が送られるべき複数のオブジェクトを特定する第２の識別子と、前記第１と第２の識別子の間をマッピングするためのマッピング情報を記憶する、前記ディスパッチャーの記憶モジュールで実行される記憶手段と、
    前記インターフェース手段からの要求を受信し、前記マッピング情報に応答して前記少なくとも１つのエージェントモジュールに前記要求を送出する、前記ディスパッチャーの要求処理モジュールで実行される要求処理手段と、
    要求の受信と送出を同時に行う複数のスレッドを実行する手段と、
    メンテナンス動作を実行する手段と、
    を備えることを特徴とするコンピュータ。
12. オペレーティング・システムと、少なくとも１つの記憶媒体と、前記少なくとも１つの記憶媒体へのアクセスを要求するコーラと前記オペレーティング・システムとの間をインターフェースするインターフェース手段と、前記オペレーティング・システムと前記記憶媒体との間をインターフェースし、各エージェントモジュールは少なくとも１つのファイルシステムフォーマットに対応している複数のエージェントモジュールと、前記少なくとも１つの記憶媒体へのアクセス要求を受取って処理するディスパッチャとを具備するコンピュータにおいて、
    前記ディスパッチャーは、
    少なくとも１つのエージェントモジュールを特定する少なくとも１つの第１の識別子と、要求が送られるべき複数のオブジェクトを特定する第２の識別子と、前記第１と第２の識別子の間をマッピングするためのマッピング情報を記憶する、前記ディスパッチャーの記憶モジュールで実行される記憶手段と、
    前記インターフェース手段からの要求を受信し、前記マッピング情報に応答して前記少なくとも１つのエージェントモジュールに前記要求を送出する、前記ディスパッチャーの要求処理モジュールで実行される要求処理手段とを備え、
    前記マッピング情報は複数の制御ブロックを備え、前記制御ブロックは、少なくとも１つのエージェント制御ブロックと、前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのボリューム制御ブロックと、前記少なくとも１つのエージェント制御ブロックと前記少なくとも１つのボリューム制御ブロックに接続された少なくとも１つのパス制御ブロックと、前記少なくとも１つのボリューム制御ブロックと前記少なくとも１つのエージェント制御ブロックとに接続された少なくとも１つの反復制御ブロックとを備えることを特徴とするコンピュータ。
13. ポートと、前記ポートに割り当てられ、前記要求に対応するメッセージを受取るように適用される複数のオブジェクトを更に備え、
    前記オブジェクトは前記エージェント制御ブロック、前記ボリューム制御ブロック、前記パス制御ブロック及び前記反復制御ブロックに関連しており、そして前記ポートを通して前記オブジェクトから前記メッセージを取り出し、前記要求を処理する手段を備えることを特徴とする請求項１２に記載のコンピュータ。
14. 前記要求処理手段は、前記メッセージが受信されるオブジェクトを特定するための識別子に基づいて、前記オブジェクトからの要求を前記少なくとも１つのエージェントモジュールに送出する手段を備えることを特徴とする請求項１３に記載のコンピュータ。
15. 前記オブジェクトは、前記インターフェース手段からの要求を受取るためのファイルマネージャオブジェクトを備え、前記要求処理手段は、前記要求に含まれる情報に基づいて、前記ファイルマネージャオブジェクトからの要求を前記少なくとも１つのエージェントモジュールに送出する手段を備えることを特徴とする請求項１３に記載のコンピュータ。
16. オペレーティング・システムと、少なくとも１つの記憶媒体と、前記少なくとも１つの記憶媒体へのアクセスを要求するコーラと前記オペレーティング・システムとの間をインターフェースするインターフェース手段と、前記オペレーティング・システムと前記記憶媒体との間をインターフェースし、各エージェントモジュールは少なくとも１つのファイルシステムフォーマットに対応している複数のエージェントモジュールとを具備するコンピュータにおいて、前記少なくとも１つの記憶媒体へのアクセス要求を扱って処理する方法であって、
    前記複数のエージェントモジュールを特定するための少なくとも１つの第１の識別子と、要求が送出される複数のオブジェクトを特定するための第２の識別子と、前記第１と第２の識別子をマッピングするマッピング情報とをメモリに記憶する工程と、
    要求処理モジュールで、前記インターフェース手段からの要求を受信する工程と、
    前記メモリの前記マッピング情報に応答して前記少なくとも１つのエージェントモジュールに前記要求を送出する工程と、
    要求の受信と送出を同時に行う複数のスレッドを実行する工程と、
    メンテナンス動作を実行する工程と、
    を備えることを特徴とする方法。
17. オペレーティング・システムと、少なくとも１つの記憶媒体と、前記少なくとも１つの記憶媒体へのアクセスを要求するコーラと前記オペレーティング・システムとの間をインターフェースするインターフェース手段と、前記オペレーティング・システムと前記記憶媒体との間をインターフェースし、各エージェントモジュールは少なくとも１つのファイルシステムフォーマットに対応している複数のエージェントモジュールとを具備するコンピュータにおいて、前記少なくとも１つの記憶媒体へのアクセス要求を扱って処理する方法であって、
    前記複数のエージェントモジュールを特定するための少なくとも１つの第１の識別子と、要求が送出される複数のオブジェクトを特定するための第２の識別子と、前記第１と第２の識別子をマッピングするマッピング情報とをメモリに記憶する工程と、
    要求処理モジュールで、前記インターフェース手段からの要求を受信する工程と、
    前記メモリの前記マッピング情報に応答して前記少なくとも１つのエージェントモジュールに前記要求を送出する工程とを有し、
    前記マッピング情報を記憶する工程は、
    少なくとも１つのエージェント制御ブロックを記憶する工程と、
    前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのボリューム制御ブロックを記憶する工程と、
    前記少なくとも１つのエージェント制御ブロックと前記少なくとも１つのボリューム制御ブロックとに接続された少なくとも１つのパス制御ブロックを記憶する工程と、
    前記少なくとも１つのボリューム制御ブロックと前記少なくとも１つのエージェント制御ブロックとに接続された少なくとも１つの反復制御ブロックを記憶する工程とを備えることを特徴とする方法。
18. 前記要求処理モジュールは、
    ポートと、前記エージェント制御ブロック、前記ボリューム制御ブロック、前記パス制御ブロック及び前記反復制御ブロックに関連する前記複数のオブジェクトを備え、
    前記複数のオブジェクトは前記ポートに割り当てられ、前記要求に対応するメッセージを受取るように適用され、
    前記方法は更に、前記ポートを通して前記オブジェクトからのメッセージを取り出して前記要求を処理する工程を備えることを特徴とする請求項１６に記載の方法。
19. 前記要求を処理する工程は、前記メッセージが受信されるオブジェクトを特定するための識別子に基づいて、前記オブジェクトからの要求を前記少なくとも１つのエージェントモジュールに送出する送出工程を備えることを特徴とする請求項１８に記載の方法。
20. 前記送出工程は、
    前記要求がボリュームに関連したオブジェクトに送られる場合は、ボリュームオブジェクトから取り出された情報に基づいてボリューム制御ブロックを取り出し、
    前記ボリューム制御ブロックから取り出された情報に基づいてエージェント制御ブロックを取り出し、
    前記エージェント制御ブロックから取り出された情報に基づいて前記エージェントモジュールの１つに前記要求を送出し、
    前記エージェントモジュールで受信された応答に従って前記インターフェース手段に応答することを特徴とする請求項１９に記載の方法。
21. 前記送出工程は、
    前記要求がパスに関連したパスオブジェクトに送られる場合は、前記パスオブジェクトから取り出した情報に基づいてボリューム制御ブロックを取り出し、
    前記パス制御ブロックから取り出した情報に基づいてエージェント制御ブロックを取り出し、
    前記エージェント制御ブロックから取り出した情報に基づいて前記エージェントモジュールの１つに前記要求を送出し、そして
    前記エージェントモジュールから受信した応答に従って前記インターフェース手段に応答することを特徴とする請求項１９に記載の方法。
22. 前記送出工程は、
    前記要求が反復オブジェクトに関連するオブジェクトに送られる場合は、前記反復オブジェクトから受取った情報に基づいてボリューム制御ブロックを取り出し、
    前記反復制御ブロックから受取った情報に基づいてエージェント制御ブロックを取り出し、
    前記エージェント制御ブロックから受取った情報に基づいて前記エージェントモジュールの１つに前記要求を送出し、
    前記反復モジュールが別のボリュームに移動される必要がある場合、前記反復制御ブロックを新たなボリューム制御ブロックに移動し、前記エージェント制御ブロックから受取った情報に基づいてエージェントモジュールの１つに要求を送出し、
    前記エージェントモジュールから受信した応答に従って前記インターフェース手段に応答することを特徴とする請求項１９に記載の方法。
23. 前記オブジェクトは、前記インターフェース手段からの要求を受取るファイルマネージャオブジェクトを備え、
    前記方法は更に、前記要求に含まれる情報に基づいて、前記ファイルマネージャオブジェクトから前記少なくとも１つのエージェントモジュールに前記要求を送出する工程を備えることを特徴とする請求項１８に記載の方法。
24. 前記要求に含まれる情報に基づく送出工程は、
    前記要求がマルチボリューム要求であれば、前記要求により影響を受けるボリュームを決定し、
    ファイルマネージャオブジェクトに送られたメッセージから取り出された情報に基づいて、前記ボリュームのボリューム制御ブロックを取り出し、
    前記ボリューム制御ブロックから取り出した情報に基づいてエージェント制御ブロックを取り出し、
    前記エージェント制御ブロックに関連したエージェントモジュールが同じであれば、前記エージェント制御ブロックから取り出された情報に基づいて前記エージェントモジュールの１つに前記要求を送出し、
    前記エージェントモジュールが同じでない時は、前記ボリュームのそれぞれに対する要求を連続して作成して送出し、
    前記エージェント制御ブロックから取り出した情報に基づいて、前記エージェントモジュールの１つに前記要求を送出し、
    前記エージェントモジュールから受取った応答に従って前記インターフェース手段に応答することを特徴とする請求項２３に記載の方法。
25. 前記要求に含まれる情報に基づく送出工程は、
    前記要求がボリュームの実装要求の場合は、所定のメッセージを作成し、
    前記エージェントモジュールの１つが当該ボリュームを実装できるまで、連続して前記エージェントモジュールに前記所定のメッセージを送出し、
    前記エージェント制御ブロックから取り出した情報に基づいて、前記エージェントモジュールの１つに前記要求を送出し、
    前記エージェントモジュールの１つから受信した応答に従って前記インターフェース手段に応答することを特徴とする請求項２３に記載の方法。
26. 前記要求に含まれる情報に基づく送出工程は、
    前記要求がパス名決定要求であれば、前記メッセージの一部からボリュームを決定し、
    所定のボリュームに関連するボリューム制御ブロックから取り出した情報からエージェント制御ブロックを取り出し、
    前記エージェント制御ブロックから取り出した情報に基づいて、前記エージェントモジュールの１つに前記要求を送出し、
    前記エージェントモジュールの１つから受信した応答に従って前記インターフェース手段に応答することを特徴とする請求項２３に記載の方法。
27. 少なくとも１つのファイルシステムフォーマットの１つに従って構成された記憶媒体へのアクセスを要求するために適用される少なくとも１つのコーラを含むコンピュータにおいて、前記記憶媒体へのアクセス要求を処理する方法であって、
    少なくとも１つのフォーマットエージェント手段を特定する少なくとも１つの第１の識別子と、ディスパッチポートに割り当てられた複数のオブジェクトを特定する第２の識別子と、前記第１と第２の識別子の間をマッピングするためのマッピング情報を記憶する工程と、
    コーラからの要求をインターフェース手段で受信する工程と、
    前記ディスパッチポートを含むディスパッチ手段において、前記インターフェース手段からの要求を受信する工程と、
    前記記憶手段のマッピング情報に応答して、前記フォーマットエージェント手段の１つに前記要求を送出する工程と、
    ディスパッチ手段の前記インターフェース手段からの要求を受信する工程と、
    前記ファイルシステムフォーマットに対応する前記フォーマットエージェント手段の１つを介して前記記憶媒体をアクセスする要求を処理する工程とを備え、
    前記マッピング情報を記憶する工程は、
    少なくとも１つのエージェント制御ブロックを記憶し、前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのボリューム制御ブロックを記憶し、前記少なくとも１つのボリューム制御ブロックと前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つのパス制御ブロックを記憶し、前記少なくとも１つのボリューム制御ブロックと前記少なくとも１つのエージェント制御ブロックに接続された少なくとも１つの反復制御ブロックを記憶することを特徴とする方法。
28. 要求の受信と送出を同時に行う複数のスレッドを実行する工程を更に有することを特徴とする請求項２７に記載の方法。
29. 前記システムのメンテナンス動作を実行する工程を更に備えることを特徴とする請求項２７に記載の方法。

Images