(57)【要約】  コンピュータ・デバイス上でディレクトリを読む場合、リストをクライアントのアプリケーションに引き渡す際にファイルサーバは唯一のタグをリストに付加する。ファイルサーバは、ファイルが対応するファイルの物理アドレスと共に唯一なタグのリストを保持する。クライアントがファイルをオープンすることを望むと、クライアントはファイルサーバにタグを渡すことによりファイルをオープンすることができる。これによりファイルサーバは、ファイル名からファイルの物理的位置を見出すために２度目のディレクトリ検索を企てることを必要とせず、直接ファイルをロードすることができる。【特許請求の範囲】
【請求項１】
ディレクトリ構造を組み込むコンピュータ・デバイスにおけるファイル管理の方法であって、該方法は、
ａ．ファイルシステムのディレクトリのリストが前記ディレクトリにおける各々のエントリに対する唯一に識別可能なタグを含むように構成するステップと、
ｂ．クライアントに前記ディレクトリのリストを提供する場合に、エントリにより参照されるオブジェクトの物理的位置を示す前記リストにおける各々のエントリに対するタグを含む前記リストのコピーを保持するステップと、
ｃ．オブジェクトのタグの参照によりオブジェクトをオープンする要求を受理するステップと、
ｄ．前記オブジェクトの前記物理的位置を検索し、前記オブジェクトの物理的位置において前記オブジェクトをオープンするステップと、
を含む方法。
【請求項２】
前記ファイルシステムはファイルサーバにより制御され、前記ファイルサーバと１以上の異なるセッションを維持するように構成された複数のクライアントにファイルシステムサービスを提供することを特徴とする請求項１に記載の方法。
【請求項３】
前記オブジェクトは、ファイルまたは他のディレクトリまたは任意の他のエンティティを含むように選択されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記タグは配列の形式のリストで維持され、該配列において前記タグが個々のオブジェクトの前記物理的位置の検索を可能にするためのインデックスとして作用することを特徴とする請求項１乃至３の何れか１項に記載の方法。
【請求項５】
前記ファイルシステムは、読み取り専用ファイルシステムを含むことを特徴とする請求項１乃至４の何れか１項に記載の方法。
【請求項６】
前記読み取り専用ファイルシステムは、前記コンピュータ・デバイスの起動に使用されることを特徴とする請求項５に記載の方法。
【請求項７】
前記ファイルシステムは、書き込み可能なファイルシステムを含むことを特徴とする請求項１乃至４の何れか１項に記載の方法。
【請求項８】
前記保持されるリストは、本来導出された前記ディレクトリに変更がなされると無効化され、前記クライアントが名前により前記オブジェクトをオープンするようにするため、無効化されたリストにタグを有するオブジェクトをオープンすることを要求するクライアントにエラーコードを返送することを特徴とする請求項７に記載の方法。
【請求項９】
前記リストの前記保持されたコピーは、オブジェクトに対する個々の名前をさらに備え、前記保持されるリストは、本来導出された前記ディレクトリに変更がなされると無効化され、無効化されたリストのオブジェクトをオープンする要求により、前記保持されるリストにおける前記個々の名前を使用して、前記オブジェクトがオープンされるようにすることを特徴とする請求項７に記載の方法。
【請求項１０】
前記ファイルシステムは、タグおよびオブジェクトの名前により参照されるオブジェクトをオープンする要求を受理するように構成され、前記保持されるタグのリストが、本来導出された前記ディレクトリに変更がなされると無効化され、無効化されたリストのタグによりオブジェクトをオープンする要求により前記ファイルシステムが前記オブジェクトの名前を使用して前記オブジェクトがオープンされるようにすることを特徴とする請求項７に記載の方法。
【請求項１１】
前記ファイルシステムは、無効とされたリストによりオブジェクトが名前によりオープンされるようにした後に、保持されるリストを更新し、再度有効化するように構成されることを特徴とする請求項８乃至１０の何れか１項に記載の方法。
【請求項１２】
前記ファイルシステムは、保持されるディレクトリのリストを有するディレクトリにおけるエントリへの変化を生じさせる活動を監視するように構成され、タグが変化により影響を受けるといつでも、前記保持されるリストを無効化する代わりにタグが無効化され、無効化されたタグを使用して要求がなされる場合にのみ、オブジェクトが名前によりオープンされるか、または、前記ファイルシステムは、他の場合には無効化されるエントリを動的に更新するように構成されることを特徴とする請求項８乃至１０の何れか１項に記載の方法。
【請求項１３】
ａ．単一の保持されるディレクトリのリストがシステムの各々の論理駆動装置に許可されるか、
ｂ．固定数の保持されるディレクトリのリストがファイルサーバのセッション毎に許可されるか、
ｃ．複数の保持されるディレクトリのリストがクライアントの要求によりファイルサーバのセッション毎に固定または動的最大値まで許可されるか、
の何れかであることを特徴とする請求項１乃至１２の何れか１項に記載の方法。
【請求項１４】
読み取り専用ファイルシステムの使用がプロファイリングされ、前記起動過程か、または他に定められ、予測される前記コンピュータ・デバイスの動作シーケンスの間に自動的に使用するために、１以上の保持されるディレクトリのリストが予め定義され、起動ＲＯＭに含まれることを特徴とする請求項５または６、または請求項５または６に従属する場合の請求項１３に記載の方法。
【請求項１５】
請求項１乃至１４の何れか１項に規定される方法に従い動作するように構成されるコンピュータ・デバイス。
【請求項１６】
コンピュータ・デバイスを請求項１乃至１４の何れか１項に規定される方法に従い動作させるための、該コンピュータ・デバイスのためのオペレーティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・デバイスにおけるファイル管理に関し、特にコンピュータ・デバイスにおいてファイルをオープンする改良された方法に関する。
【背景技術】
【０００２】
本明細書において使用する用語であるコンピュータ・デバイスはあらゆる形式の電動のコンピュータ・デバイスを含むように拡張して考えられ、データ記録装置、ハンドヘルドおよびパーソナルコンピュータを含むあらゆるタイプまたは形式のコンピュータ、携帯電話機、スマートフォン、そして、通信、画像の記録および／または再生、計算機能を単一装置内で組み合わせるコミュニケータを含むあらゆるフォームファクタの通信装置、および他の形式の無線および有線の情報装置を含む。
【０００３】
コンピュータ・デバイス上のファイルは永続的な名称を付されたデータの格納装置であり、単一のビット・ストリームとして提示される。ファイル管理は、最も単純なコンピュータ・デバイスは別として全てのオペレーティングシステムの主なタスクの１つである。初期のスタンドアロンのパーソナルコンピュータでは、マイクロソフト社の最初のＯＳ（オペレーティングシステム）に対してＤＯＳ（ディスク・オペレーティングシステム）という略称を選択したことにも示されるように、ファイル管理は恐らく間違いなく主なオペレーティングシステムのタスクであった。ユーザインタフェースはより複雑になり、ネットワーク化され、接続されたシステムの増大およびコンピューティングと通信の装置の融合によりネットワークおよびリンク管理の重要性は増したが、ファイル管理は依然としてあらゆる先端的コンピュータ・デバイスのコアとなる機能の１つである。
【０００４】
近年のオペレーティングシステムにおける最も基本的なファイル管理は、
・システムのディレクトリまたはファイル・インデックスの維持すること、
・要求に応じて名称付きファイルをオープンまたは生成すること、
・コンテンツの読み取りまたは書き込みを可能にすること、
・ファイルまたは内容の削除を可能にすること
である。ファイル管理の処理をするオペレーティングシステムの部分はファイルシステムと呼ばれる。
【０００５】
ファイルシステムはＯＳの基本的な部分であるが、ファイルシステムは、システムの最も重大なボトルネックの１つであることがよくあり、多重のファイルシステムアクセスは、それ故あらゆるコンピュータ・デバイスの動作の実効速度を低下させる。これには２つの主な理由が存在する。
【０００６】
・ファイルシステムが行う必要のある仕事の複雑さの故に、データファイルの書き込みと検索は計算上極めてコストを要しうる。大部分のファイルシステムは複数のレベルの間接的手法を使用して、特定のハードウエアの特性と非効率性を抽象化し、また格納する必要のある種々のタイプのデータに論理的構造を課す。さらに読み出し専用（ＲＯ）でない全てのファイルシステムは、その管理するデータの内容の変化に動的に対処しなければならない；ファイルシステムは書き込みの発生の際に、システムの既存データの完全性が損なわれることのないことを保証し、また「ディスク・フル」および「不良ブロック」などのエラーの状況を予測し、処理しなければならない。
【０００７】
・さらに重要なことは、永続的ファイルを格納する物理的媒体（ディスク駆動装置であるか否かにかかわらず、歴史的理由からディスクまたは駆動装置を一般に意味する）は殆ど常にコンピュータ・デバイスを含む他のハードウエアよりアクセス速度が遅い。これは、パーソナルコンピュータに使用される従来のフロッピー（登録商標）およびハードディスク駆動装置では最も顕著であり、これらの装置は比較的遅い金属化合物の磁気格納装置に依存する。一般的なフロッピー（登録商標）ディスクのデータ伝送速度は１５０キロビット／秒に過ぎない。ハードディスクは遥かに速く、今や１００メガビット／秒の速度に近づくが、これは今や１．５ギガビット／秒を超える可能性のある装置のランダムアクセスメモリ（ＲＡＭ）の速度より依然として遥かに遅い。その比較的遅い生のデータ伝送速度とともに、ディスク駆動装置は、また媒体を物理的に回転させる必要から不利な影響を受ける；これはより近代的なＣＤおよびＤＶＤ駆動装置と共有する特性であり、これらはレーザ技術に依存し、データを読み、代表的にはフロッピー（登録商標）ディスクの速度の１０倍に達する速度でデータを書き込むことができ、フロッピー（登録商標）ディスクの速度の約５０倍の速度でデータを読み込むことができる。全てのディスク媒体に関する問題は、比較的起動が遅く；ディスクを読み出しうる前に正しい位置まで回転させなければならないので、直ちにデータを供給することができず、駆動装置の読み出し準備ができるのを待つ必要からさらに遅延が増すことである。
【０００８】
これらの考察はここ数年重要性を増しつつあるが、これは移動電話機、パーソナル・デジタル・アシスタント（ＰＤＡ）およびデジタルカメラなどのバッテリで動作するモバイル・コンピュータ・デバイスへの適用によるものである。このクラスの装置は一般に固定の格納装置にディスク媒体を使用せず（アップル社のｉＰｏｄなどの幾つかのＭＰ３プレイヤーは例外である）、フラッシュメモリディスク、ＣＦ（Compact Flash）カード、ＭＭＣカード（MultiMedia Cards）、メモリースティック、ＳＭ（Smart Media）（登録商標）カードおよびＳＤ（Secure Digital）カードなどの固体媒体を一般に使用する。
【０００９】
・これらの固体媒体はディスク駆動装置と同様の遅延の問題に困ることはないが、そのデータ伝送速度は依然としてＲＡＭより遥かに遅く（代表的には１メガビット／秒から２メガビット／秒）、従って全体的装置性能を改善するためにディスクアクセスを減らそうとする上記の動機は同様に当てはまる。
【００１０】
・さらに良く知られていることは、読み出し専用メモリ（ＲＯＭ）へのアクセス速度はランダムアクセスメモリ（ＲＡＭ）の場合より遥かに遅く；これが、大部分のパーソナルコンピュータがＲＯＭの内容をＲＡＭにコピーし、メモリアクセスを遅いＲＯＭの代わりに速いＲＡＭへ対応付けし直し、性能を改善する１つの理由である。セル電話機、ＰＤＡおよびデジタルカメラなどのＲＯＭで起動しバッテリで動作するモバイル・デバイスのユーザは立ち上がり時間がより速いことにより大きな利点となり得るが、これは、電源投入と装置が動作状態になる間の遅延がこれらの装置のユーザにとって欲求不満と見られることが多いからである。ＲＯＭのファイルシステムを高速化するものは何であれ、起動時間を減らし、このクラスの装置にとってそれ故きわめて望ましく、少なからず有益である。
【００１１】
・同様に重要なのは、固体格納装置へのアクセスは、バッテリで動作する装置がより速い速度で電力を消費することに繋がり、これは明らかにバッテリの再充電または取替えの間の使用可能寿命をより短くする結果となる。それ故、ファイルシステムへのアクセスを最小にするあらゆる技術は電力の保存に役立ち、装置可用性の増大となる。
【００１２】
コンピュータシステム設計者およびソフトウエア設計者は長年の間、コンピュータ・デバイス全体として動作を高速化するために、ファイルシステムおよび物理的ディスク両方へのアクセスを最小にする方法を求めてきた。大部分の速度改善はキャッシュ技術の使用に頼っている。
【００１３】
例えばデータブロックの一部をディスクなどのより遅い媒体から読む必要がある場合、ブロック全てを読み、読み取りキャッシュにおけるＲＡＭなどのより速い媒体に一時的に格納することができる；これは、データが既にキャッシュにあるので、その後同じブロックからデータを読むのにより遅い格納媒体にアクセスする必要がないことを意味する（この方法でキャッシュからデータを読むことができることはキャッシュヒットとして知られる）。書き込みキャッシュ(レイジー書き込みとしても知られている）は、複数回の非効率的書き込み動作を無くすことにより少し異なるように動作し；メモリのディスクに書かれる少量のデータは、物理的書き込みを行うに値するほど十分なデータが集まるまでキャッシュに保持される。
【００１４】
この発明の分野に対して特別な関心があり、それほど知られていないキャッシュメカニズムは名前キャッシュであり、これはファイルシステムにおける特定のボトルネックに提供するために設計されたものである。
【００１５】
名前キャッシュが動作する前提では、ファイルシステムが一般にファイルの物理的位置に対するポインタおよびディレクトリを論理的階層構造におけるその名前と共に格納する。そのような構造では単一のルートのディレクトリは、常にファイルの取出しが始まる最初の場所である；ルート(つまりトップレベル）のディレクトリは幾つかのディレクトリエントリを含み、これらのエントリはファイルを直接指定できるか、または代わりに１以上の第２のレベルのディレクトリを指定することができる。これら第２のレベルのディレクトリは、自らファイルを直接指定することができるか、または第３のレベルのディレクトリを指定することができる。このディレクトリのネスティングは深さ方向に多数のレベルまで続きうる。
【００１６】
名前キャッシュが扱うように設計されるボトルネックは、ファイルをその固有のパス名から出発してディスク上で物理的に位置づけるのに使用される方法から生じ、パス名はファイル名を含み、ファイル名はファイルが見つかるサブディレクトリによりプレフィックスを付され、サブディレクトリは次にサブディレクトリが見つかるディレクトリによりプレフィックスを付される、などによりルートディレクトリに戻る。
【００１７】
ファイルを物理的に位置づけるためにパス名が与えられれば、ファイルシステムは、
１）ファイル名を表す文字列をその独立のディレクトリおよびファイル要素に分解し、
２）ディスク上のルートディレクトリを見つけ、
３）次レベルディレクトリの名称に対し適合するものが見つかるまで各々のディレクトリのエントリを読むことを繰り返し、
４）次レベルディレクトリのその物理的位置を含む属性を検索し、次レベルディレクトリをディスク上に見出し、
５）最低位レベルのディレクトリに達するまで、パスの各々のディレクトリについてステップ３および４を繰り返し、
６）ファイル名について適合するものが見つかるまで最低位レベルのディレクトリの各々のエントリを読むことを繰り返し、
７）ファイルの物理的位置を含むファイル属性を検索する、
必要がある。
【００１８】
文字列比較、ファイルシステム探索およびファイルシステムの読み出しの繰り返しの多くの回数は名前キャッシュの使用により削減されることができる。これは直近にアクセスしたファイルの物理的位置およびディレクトリをその名前と共に格納する。
【００１９】
ＤＮＬＣ（ディレクトリ／動的名称ルックアップ・キャッシュ）はＵｎｉｘ(登録商標)／Ｌｉｎｕｘ系オペレーティングシステム（まとめて＊ｎｉｘとして参照される）で使用される名前キャッシュなどに関して一般的に実装される。ＤＮＬＣによりシステム上のファイルをオープンしようとする場合、まずハッシュアルゴリズムによりキャッシュにおける完全修飾パス名を調べ、キャッシュヒットのキャッシュエントリから直接ファイルの物理的位置を検索し、キャッシュにファイル名がなければキャッシュにおいてディレクトリを調べ（最も内側から外に向かって）、ディレクトリの１つにキャッシュヒットがあれば、その物理的位置をキャッシュから得ることができ、検索はディスク上のそのポイントから行うことができる。キャッシュにおいて少なくとも幾つかのパス名が提供されると、この方法は頻繁にアクセスするファイルのディスクアクセスを軽減するのに有効でありうる。
【００２０】
全ての現在のオペレーティングシステムは、ディレクトリのリスト要求およびファイルのオープン要求を別個の、独立の動作と見る。
【００２１】
この発明は、ディレクトリのリスト要求が分離してなされる非常に稀な場合を基本にしており、ディレクトリのリストの極めて多くは、そのリストにおいて返されるファイルの１つをオープンすることを予期して要求される。コンピュータ・デバイスにおけるディレクトリ検索が最も一般的に使用されるケースは、ディレクトリを走査し、そのディレクトリにおいてオープンするべき１以上のファイルを選択するアプリケーションに続く要求である。
【００２２】
代表的な例は多くのオペレーティングシステム、特に起動過程において見ることができる。例えばマイクロソフト社のＷｉｎｄｏｗｓ(登録商標)では、多くのファイルは＼ｗｉｎｄｏｗｓ＼ｓｙｓｔｅｍ３２などのシステムディレクトリからロードされる、一方頻繁にアクセスされるＵｎｉｘ(登録商標)およびＬｉｎｕｘのシステムディレクトリは／ｅｔｃ／ｂｉｎおよび／ｌｉｂを含む。シンビアンソフトウェア社の移動電話機用の先端的オペレーティングシステムである、ＳｙｍｂｉａｎＯＳ（商標）は、起動時、および、実行可能ファイルおよびリソースファイルの読み込み時の双方で、＼ｓｙｓおよび＼ｒｅｓｏｕｒｃｅなどのディレクトリにアクセスする。
【００２３】
このタスクを実行する通常の方法は、ファイルサーバからディレクトリのリストを要求することにより始まるが、ファイルサーバは、複数のクライアントのアプリケーションおよび処理に対してファイルシステムアクセスを提供することに対応する要素である。ディレクトリのリストはディスク上でディレクトリ情報を見つけ、次いで各々のエントリを見て回り、クライアントに返されるリストを構築することにより生成される。次いでクライアントはファイルのリストを検索し、ファイル名をファイルサーバに渡して、ファイルをオープンするこの点でディレクトリを再度読み、再び検索して、ファイルエントリおよびファイルエントリからディスク上のファイルの位置を見つける。
【００２４】
この処理の明らかな欠点は、ディレクトリ検索とそれに続くファイルのオープンとの間の関係認識の失敗により、完全に不要な２度目のディレクトリ検索が必要になることである。ファイル位置に関する全ての情報は、ディレクトリリストが最初に構築されたときには利用可能であったが、無視される。従って、ファイルを実際にオープンする場合にこの情報を求めてディレクトリを再度検索するのに、時間およびそれによるバッテリ電力が消費される。
【００２５】
１以上のディレクトリのリストは読み取りキャッシュに保持することができ、この場合物理的ディスクに戻るよりメモリにキャッシュされたコピーを通じて検索するほうが疑いなく早い。さらにファイルまたはディレクトリが頻繁にオープンされるならば、その場合その物理的位置を名前キャッシュに保持することが可能である。
【００２６】
しかしこれらの方法のいずれも、最初のアクセスが廃棄されるため２度アクセスし、読み、検索しなければならない有用な情報（ディレクトリのリスト）に関する基本的問題を解決していない。読み取りキャッシュがディレクトリのコピーを含めば、これだけでもディスクからディレクトリを読む必要がなくなる。読み取りキャッシュは２度検索しなければならず；名前キャッシュは、未だオープンされていないファイルには役立ちそうにない。
【発明の開示】
【発明が解決しようとする課題】
【００２７】
それ故コンピュータ・デバイスにおけるファイル管理の改善された方法を提供することが本発明の目的である。
【課題を解決するための手段】
【００２８】
本発明の第１の態様によれば、ディレクトリ構造を組み込むコンピュータ・デバイスにおけるファイル管理の方法が提供され、本方法は、
ａ．ファイルシステムのディレクトリのリストがディレクトリにおける各々のエントリに対する唯一に識別可能なタグを含むように構成するステップ、
ｂ．クライアントにディレクトリのリストを提供する場合に、そのエントリにより参照されるオブジェクトの物理的位置を示すリストにおける各々のエントリに対するタグを含むリストのコピーを保持するステップ、
ｃ．オブジェクトのタグの参照によりオブジェクトをオープンする要求を受理するステップ、
ｄ．オブジェクトの物理的位置を検索し、オブジェクトの物理的位置においてオブジェクトをオープンするステップ、
を含む。
【００２９】
本発明の第２の態様によれば、第１の態様の方法に従い動作するように構成されるコンピュータ・デバイスが提供される。
【００３０】
本発明の第３の態様によれば、装置が第１の態様の方法に従い動作するようにするコンピュータ・デバイスのためのオペレーティングシステムが提供される。
【発明を実施するための最良の形態】
【００３１】
本発明の実施形態を、さらに実施例のみの方法により以下に説明する。
【００３２】
本発明によりクライアントがディレクトリのリストを要求する場合、ファイルシステムは２つのリストを構築する；１つはクライアントに返されるが、他方はサーバにより保持される。クライアントに返されるリストは標準のディレクトリリストであり、各々のエントリはサーバ側のリストにおいて対応するエントリを参照するタグを含むように拡張される。サーバの保持するリストは、駆動装置上の各々のファイルの物理的位置に関する情報（これはファイルをオープンするために必要な情報である）と共に；(最低限）タグを含む。クライアントに返される各々のエントリはタグを付されているので、クライアントは、自分のリストとサーバ側のリストとの間のリンクを損なうことなく自らのリストを自由に分類することができることに注意されたい。
【００３３】
好ましくは、サーバリストは配列へのインデックスとしてまた動作するリストにおける各々の項目のタグと共に配列において保持される。
【００３４】
クライアントがファイルをオープンすることを望む場合、新しいファイルのオープン方法がファイルサーバにより提供される。ファイル名またはパス名をパラメータとして渡す代わりに、この新しい方法はディレクトリのリストにおける１つのエントリに対するタグをパラメータとして採用する。
【００３５】
ファイルサーバは、次いでこのタグを使用してその配列における位置情報を見つけ、これをファイルシステムに渡す。ファイルは、次いでこのディレクトリを再度検索することを必要とせず、直ちにオープンすることができる。
【００３６】
この方法は、キャッシュのヒットが生じる場合にも、依然としてファイルを名前によりオープンしなければならず、余分な検索のオーバヘッドを招く、ディレクトリのリストを単にキャッシュするシステムに対して明らかに有利である。ユニコードのファイル名を使用する特に最近のシステムにおいて、これに伴う複数の文字列の比較は些細なものではない。
【００３７】
読み取り専用ファイルシステム（ＲＯＭおよびＲＯＦＳディスクに対するものなど）では、ディスクの内容が変化しないので既に説明したステップで十分である。それ故ディレクトリのリストの検索後ファイルがロードされる全ての場合に性能の改善がある；この発明のファイルシステムの革新により、ファイルを、検索を含むことなくタグにより直接オープンすることが常に可能になる。
【００３８】
以上の革新を書き込み可能な駆動装置に拡張するために、ディレクトリリストへの変更に対処するメカニズムが含まれることがある。そのような変更は、例えば既存ファイルの長さの変更、ファイルの削除、または新ファイルの生成を含むことができる。
【００３９】
以上を達成するための幾つかの可能なメカニズムについて、次に説明する。
【００４０】
最も簡単なメカニズムは、ディレクトリが変更されるとサーバ側のリスト全体を無効化するフラグを立てることである。この場合タグを渡すことによりエントリにより参照するファイル（または任意のオブジェクト）をオープンしようとすると、その場合ファイルサーバが、クライアントにエラーコードを返すようにし、これにより次にファイル（またはオブジェクト）を名前によるオープンに立ち戻る。
【００４１】
上記メカニズムの修正された実装により、サーバ側リストがファイル名、およびタグとファイルの物理的位置を追加して格納することを要求する。この場合無効リストのファイルにタグを渡すことにより、以上の例におけるクライアントよりむしろファイルサーバが、クライアントには透過的にファイルまたはオブジェクトを名前によるオープンに立ち戻るようにする。
【００４２】
サーバ側リストにおけるファイル名の格納の必要を避ける別のメカニズムでは、タグとファイル名の両方をパラメータとして採用するファイルをオープンする方法の追加バージョンを提供する。このメカニズムは書き込み可能なファイルシステムと共に使用することができ、サーバ側リストにおけるファイル名の格納を必要とせず、上記のサーバが名前によるファイルのオープンへの透過的な立ち戻りを可能とする。
【００４３】
この実装においてサーバ側リストにファイル名を保持する必要のないことは、メモリの利用に関して特に有利である。全ての名前（特に長いユニコード名）を格納することはメモリに関して特にわずらわしいことでありえ；結果としてＤＮＬＣの名前キャッシュの多くの＊ｎｉｘ実装により、キャッシュされる名前の長さを約１５文字に制限することが必要であることが分かったが、これは名称キャッシュ方式の利用性に大きく影響する。バッテリで動作するモバイル・コンピュータ・デバイスは、特にリソースに制限があり、そのためサーバリストが書き込み可能な駆動装置に対してもタグおよび物理的位置を単に格納できる方法は極めて望ましく、有益であると考えられる。
【００４４】
オプションで後の２つのメカニズムのいずれかにより、サーバによる名前を指定されたファイルのタグによりオープンすることに戻ると同時にサーバ側リストを自動的に更新することができる。
【００４５】
ファイルサーバがディレクトリに潜在的に変化を引き起こす動作を積極的に監視し、リストが常に有効であることを確かめるためにディレクトリのリストの内容を動的に調整することができるようにすることにより、一組のより複雑なメカニズムを開発することもできる。例えば、サーバが、ディレクトリ上にファイルをオープンするリストの有無を調べ、その後に変更を行い、サーバ側配列における単一のエントリを無効にするか、または新しい情報によりエントリを理想的に更新する、ように構成することができる。
【００４６】
単一のエントリが無効にされる場合、エラーコードがクライアントに返されるか、またはサーバリストが上記のようにファイル名を含めば、サーバは名前によりファイルをオープンすることに自動的に戻ることができるが；サーバ側のリストのエントリを更新し、同時に再有効化することも選択肢として可能である。
【００４７】
ＲＯＭ／ＲＯＦＳ駆動装置への本発明の適用は、装置の立ち上がり時間を直接改善するので最も重要である。本発明のこの形式の単純さは、サーバ側リストの初期生成と格納以上に、重大な実行時のオーバヘッドがないことを意味し；このオーバヘッドが遅い外部媒体よりむしろコンピュータ・デバイスの内部メモリを含むので、初期オーバヘッドは、タグによりファイルをオープンする新しい要求が最初に使用されるときにほぼ確実に償われる。
【００４８】
この発明の１つの特別な利点は、以前のクライアントのＡＰＩ（アプリケーション・プログラム・インタフェース）との両立性を損なうことなく、この発明の利点を大部分のファイルシステムのＡＰＩに含めることができることである。唯一必要な変更は、通常１以上のファイルをオープンするＯｐｅｎ（）関数であり、この関数はパラメータとしてタグをファイル名に加えて採用するか、またはファイル名の代わりに採用するかのいずれかである。とはいえ、あるシステムではこの発明を使用するために変更を必要とすることがあることは認められるが、この発明を使用するように適合する場合、ディレクトリ検索およびファイルをオープンすることを単一の動作としてカプセル化する方法は、大抵の場合動作速度および電力消費に関して利益を得る。
【００４９】
ファイルサーバがディレクトリリストをどれだけ多く保持すべきかを決める幾つかの方法があり、その例を次に概括する。
【００５０】
・単一のサーバ側リストは各々の論理的駆動装置の全てのファイルセッションに対して提供することができ；これは、１台のクライアントが単一のファイルセッションにおいてファイルをロードしようとしているか、または単一のディレクトリが全てのファイルセッションにより使用されている状況では有益である。しかしながら、ファイルサーバは、複数のクライアントが互いに他を締め出すことなくファイルにアクセスすることを認めるように使用されるので、以上のような状況は実際には比較的稀にしか起こりそうにない。
【００５１】
・ファイルセッション毎に１つのサーバ側リストを提供することができる。これは単一のサーバ側リストの場合より、潜在的により多くのメモリを使用するが、複数セッションがファイルサーバによりオープンされる場合には依然有益である。
【００５２】
・ファイルセッション毎に複数のサーバ側リストを提供することもできる；これは固有の数によるか、または追加の方法を導入するかのいずれかにより実装することができるが、追加の方法は全てのファイルセッションにある最小数のリストを与えるが、またセッションがメモリ使用およびシステム負荷のようなファクタに依存して固定の最大値か、または動的な最大値のいずれかまで余分のリストを要求することを許可する。この場合、セッションに複数のリストがある場合、サーバは使用中の全てのタグが全てのリストについて一意であることを保証する必要があることに注意されたい。
【００５３】
・起動ＲＯＭにおいて共通に使用されるシステムディレクトリの事前にコンパイル済みのリストを使用することができ、これにより多数の動作がディレクトリ検索を行うことなく進行することができ、より早い起動時間に関して特に有益と考えられる。
【００５４】
これらのオプションのうちどれが個々の状況において最良であるかは、共通の使用パターンを見つけるために装置のプロファイルを見ることにより決めることができる。当業者はそのようなプロファイルを見ることを達成する方法を知り、また速度に対するメモリ使用における必要なトレードオフの状況により、先立って厳密に規定できないことも理解する。
【００５５】
従って、本発明によりコンピュータ・デバイスのディレクトリを読む場合、ファイルサーバは、リストをクライアントのアプリケーションに渡す場合に、リストに固有のタグを付加する。ファイルサーバは固有のタグリストをタグが対応するファイルの物理的アドレスと共に保持する。クライアントがファイルをオープンすることを望むと、クライアントはタグをファイルサーバに渡すことによりファイルをオープンすることができる。これによりファイルサーバは、ファイルのファイル名からファイルの物理的位置を見つけるために２度目のディレクトリ検索を計画することを必要とせず、ファイルを直接ロードすることができる。
【００５６】
本発明は、既知のファイル管理システムに対して、以下を含む幾つかの重要な利点を提供すると考えられる。
【００５７】
・ディレクトリリストの構築時にファイルの位置情報を保持することによる、ディスクにおけるディレクトリの２重検索の回避；これはクライアントが、ディレクトリを再度検索することを必要とせず、この情報から直ちにファイルをオープンすることができることを意味する。
【００５８】
・ファイルをオープンするためのより速い検索；コードが短く、より遅い固定格納装置に対してより少ないアクセスが必要である。これは、同じディレクトリの検索の後にファイル読み込みが続く場合、特に有益である。
【００５９】
・電力効率が良くない固定格納装置、および低サイクルのＣＰＵには、アクセスのより少ないことが要求されるので、モバイル・コンピュータ・デバイスのバッテリ寿命の改善を達成することができ、ユーザの満足度および環境に関する利点を提供する。
【００６０】
・装置を起動するために使用される読み取り専用ファイルシステムに適用すると、本発明は装置の電源投入と装置が動作状態になる間の時間がより短くなる。これにより、電力を節約するために電源を切ることがよくあるが、完全な機能への素早いアクセスが極めて有用であり、重要と考えられる、移動電話機、ＰＤＡおよびデジタルカメラなどの、特に携帯型のバッテリで動作する装置のユーザ使用体験および利用性を直接改善する。
【００６１】
・望まないディスクアクセスおよびディレクトリ検索を除去することによる速度および電力消費の最適化。この点において、本発明は、ディスクアクセスは減らすが、ディレクトリの検索を除去しないキャッシュ方法より優れる。
【００６２】
・ディレクトリ全体のキャッシュと比較して、サーバ側リストのメモリ要求は遥かに少ない。本発明は、最小限としてタグおよび物理的ディスクアドレスを含む。さらに好ましい実装では、タグは配列として保持するサーバ側リストへのインデックスとして使用することができ、ファイルの物理的位置の取出しが極めて早くなり、キャッシュと違って検索の必要がない。
【００６３】
・一般のキャッシュ技術と比較して、遥かに少ない管理のオーバヘッドが達成される；保守およびキャッシュの検索は小さくない課題であり、キャッシュがなければ追加の負担が存在する。
【００６４】
・大部分のオペレーティングシステムに対して、この発明はきわめて早急に実装することができ、既存のＡＰＩおよびデータ構造に対する変更は非常に少ない。従って、既存ソフトウエアとの両立性を損なわない確率が高い。
【００６５】
・本方法は極めて汎用的であり、種々のオペレーティングシステムのＡＰＩにより使用される普通の表現およびパターン、および広く種々のプログラム言語において実装することができる。
【００６６】
・ファイルをオープンする以前の方法は変更なく動作するので、既存ソフトウエアのアプリーションを変更する必要はない。
【００６７】
・新しいファイルのオープン方法は簡単であるので、本発明の使用を決定するアプリケーション開発者の要求する労力は非常に少ない。
【００６８】
本発明を個々の実施形態を参照して説明したが、当然のことながら、修正は添付の特許請求の範囲により規定されるように、本発明の範囲内において行うことができる。
【国際調査報告】
2008503817.tif 000002
2008503817.tif 000003