JP4809663B2 - ファイルシステムと名前空間一貫性を維持するための方法およびシステム - Google Patents

Description

本発明は、一般にコンピュータに関し、より詳細には、ファイルシステムに関する。

Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳ（Ｗｉｎｄｏｗｓ（登録商標）ＮＴファイルシステム）、ＦＡＴ、ＣＤＦＳ、ＳＭＢリダイレクタファイルシステム、またはＷｅｂＤａｖファイルシステムなど、基礎となるファイルシステムを用いるＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷｉｎｄｏｗｓ（登録商標）ＸＰオペレーティングシステムなど現代のオペレーティングシステムの場合、ユーザＩ／Ｏ要求を受け取るＩ／Ｏマネージャと、ファイルシステムドライバとの間に、１つまたは複数のファイルシステムフィルタドライバを挿入することができる。一般に、（本明細書では単に「フィルタ」と呼ばれることがある）フィルタドライバは、ファイルシステムＩ／Ｏ（要求およびデータ）を、アンチウィルスソフトウェア、ファイルシステム割当てプロバイダ（ｆｉｌｅ ｓｙｓｔｅｍ ｑｕｏｔａ ｐｒｏｖｉｄｅｒ）、ファイルレプリケータ（ｒｅｐｌｉｃａｔｏｒ）、暗号化／圧縮製品に通すことなどの諸タスクを含むユーザが望む様々なファイル関連コンピューティングタスクを実行することによって、基礎となるファイルシステムを機能強化するプロセスである。

たとえば、アンチウィルス製品は、ウィルスの特徴（ｓｉｇｎａｔｕｒｅｓ）を探して、あるファイルタイプ（ｅｘｅ、ｄｏｃなど）のＩ／Ｏ往来を注視するフィルタを提供し、一方、ファイル複製製品は、ファイルシステムレベルのミラーリングを実行する。他のタイプのファイルシステムフィルタドライバは、（変更が加えられようとしているときシステムファイルをバックアップし、その結果、ユーザは元の状態に戻ることができる）システム復元、ディスク割当て実施、オープンファイルのバックアップ、削除済みファイルの復旧、ファイルの暗号化などを対象とする。したがって、ファイルシステムフィルタドライバをインストールすることにより、コンピュータユーザは、実際のオペレーティングシステムまたはファイルシステムドライバコードを変更することなしに構成要素のアップグレード、置換え、挿入、除去が可能になる形で、そのユーザが望む、また必要とするファイルシステム機能を選択することができる。

ファイルシステムフィルタは、ボリューム上でファイルおよびディレクトリ用の内部メタデータを維持することができる。フィルタが関連付けられているボリュームに対する変更により、フィルタの内部メタデータがボリュームの状態との同期から外れたものとなる可能性がある。これにより、フィルタが不正確な挙動をする、あるいはその所望の機能を果たせなくなる可能性がある。

ファイルシステムによって維持されている選択されたオブジェクトと、そのオブジェクトに関連付けられたフィルタとの間で名前空間一貫性（ｎａｍｅｓｐａｃｅ ｃｏｎｓｉｓｔｅｎｃｙ）を維持するための方法およびシステムが求められている。

手短に言えば、本発明は、ファイルシステムによって維持されている、選択されたオブジェクトと、そのオブジェクトに関連付けられたフィルタとの間で名前空間一貫性を維持するための方法およびシステムを提供する。あるプロセスが、ファイルシステムの、あるオブジェクトに対するアクセスを要求する。フィルタは、選択されたタイプの要求（または、それに関連付けられた動作（ｏｐｅｒａｔｉｏｎ））を監視し、そのオブジェクトが、そのフィルタに関連付けられた名前空間内にあるかどうか判定する。そのフィルタに関連付けられた名前空間が、そのオブジェクトに対する変更に基づいて更新される。

本発明の一態様では、要求が名前変更または削除の動作を含む。オブジェクトは、そのオブジェクトに関連付けられたポリシーを有する場合、またはそのオブジェクトが、そのようなオブジェクトの先祖である場合、フィルタに関連付けられた名前空間内にある。

本発明の他の態様では、名前変更動作により、オブジェクトを除去および／または名前変更させることができる。

本発明の他の態様では、オブジェクトは、そのオブジェクトに対するハンドルを開くことによってアクセスされる。ハンドルは、そのオブジェクトにアクセスするために使用される通信チャネルを識別する情報を含む。そのオブジェクトに対するハンドルすべてが閉じられたときそのオブジェクトを削除するべきであることを示すフラグを設定することができる。最後のハンドルが閉じられた後で、フラグが設定されたままである場合、そのオブジェクトは削除される。

本発明の一態様では、名前空間一貫性を維持することにより、フィルタで、オブジェクトが名前変更されたときオブジェクト上のポリシーを適用すること、および、削除されたオブジェクト上のポリシーを適用するのを止めることが可能になる。

他の諸態様は、以下の詳細な説明を図面と共に理解したとき明らかになろう。

例示的動作環境
図１は、本発明を実施することができる好適なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についていかなる限定も示唆することを意図するものではない。また、コンピューティング環境１００は、例示的な動作環境１００に示されている構成要素のいずれか１つ、またはその組合せに関してどんな依存性も要件も有するものと解釈すべきでない。

本発明は、多数の他の汎用または専用のコンピューティングシステム環境またはコンピューティングシステム構成と共に動作可能である。本発明と共に使用するのに適している可能性のある周知のコンピューティングシステム、環境、および／または構成の諸例には、それだけには限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロコントローラベースのシステム、セットトップボックス、プログラム可能な家庭電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

本発明について、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内で実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルと遠隔双方のコンピュータ記憶媒体内に位置することができる。

図１を参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形態で汎用コンピューティングデバイスを含んでいる。コンピュータ１１０の構成要素には、それだけには限らないが、処理装置１２０、システムメモリ１３０、および、システムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含むいくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例を挙げると、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、および、メザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。

コンピュータ１１０は、一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスすることができる任意の入手可能な媒体とすることができ、揮発性媒体と不揮発性媒体、取り外し可能媒体と取り外し不能媒体を共に含む。限定ではなく例を挙げると、コンピュータ可読媒体は、コンピュータ記憶媒体と通信媒体を含む。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性と不揮発性の、取り外し可能と取り外し不能の媒体が共に含まれる。コンピュータ記憶媒体には、それだけには限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気記憶装置、または、所望の情報を記憶するために使用することができ、コンピュータ１１０によってアクセスすることができる他の任意の媒体が含まれる。通信媒体は、典型的には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他のトランスポート機構など変調されたデータ信号中に具現化するものであり、任意の情報送達媒体を含む。「変調されたデータ信号」という用語は、情報を信号に符号化するようにその特性の１つまたは複数が設定された、または変更された信号を意味する。限定ではなく例を挙げると、通信媒体は、有線ネットワークまたは直接配線接続など有線媒体と、音響、ＲＦ、赤外線および他の無線媒体など無線媒体とを含む。上記のいずれかの組合せもまた、コンピュータ可読媒体の範囲内に含むべきである。

システムメモリ１３０は、読出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など揮発性および／または不揮発性メモリの形態でコンピュータ記憶媒体を含む。起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、通常、ＲＯＭ１３１内に記憶される。ＲＡＭ１３２は、通常、処理装置１２０によって即座にアクセス可能な、かつ／または現在操作されているデータおよび／またはプログラムモジュールを含む。限定ではなく例を挙げると、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７を示す。

コンピュータ１１０はまた、他の取り外し可能／取り外し不能の、揮発性／不揮発性のコンピュータ記憶媒体を含むことができる。例示にすぎないが、図１は、取り外し不能の不揮発性磁気媒体との間で読出しまたは書込みをするハードディスクドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２との間で読出しまたは書込みをする磁気ディスクドライブ１５１、ＣＤ ＲＯＭまたは他の光媒体など取り外し可能な不揮発性光ディスク１５６との間で読出しまたは書込みをする光ディスクドライブ１５５を示す。例示的な動作環境内で使用することができる他の取り外し可能／取り外し不能の、揮発性／不揮発性のコンピュータ記憶媒体には、それだけには限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は、通常、インターフェース１４０など取り外し不能なメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０など取り外し可能なメモリインターフェースによってシステムバス１２１に接続される。

上記で論じ、図１に示されているドライブとその関連コンピュータ記憶媒体は、コンピュータ１１０のために、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの記憶を提供する。たとえば、図１では、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７を記憶しているように示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７と同じとすることも異なるものとすることもできることに留意されたい。本明細書では、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７は、これらが最低でも異なるコピーであることを示すために異なる番号が与えられている。ユーザは、キーボード１６２、および、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、ハンドヘルドＰＣもしくは他の手書きタブレットのタッチセンサ画面などが挙げられる。これらおよび他の入力デバイスは、しばしば、システムバスに結合されるユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によっても接続することができる。モニタ１９１または他のタイプのディスプレイデバイスもまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。コンピュータはまた、モニタに加えて、スピーカ１９７やプリンタ１９６など他の周辺出力デバイスをも含むことができ、これらは、出力周辺機器インターフェース１９５を介して接続することができる。

コンピュータ１１０は、遠隔コンピュータ１８０など、１つまたは複数の遠隔コンピュータに対する論理接続を使用してネットワーク環境内で動作することができる。遠隔コンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードとすることができ、図１には、メモリ記憶装置１８１だけが示されているが、通常、コンピュータ１１０に関して上述した要素の多数または全部を含む。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。そのようなネットワーク環境は、事務所、全社コンピュータネットワーク、イントラネット、インターネットで一般的である。

コンピュータ１１０は、ＬＡＮネットワーク環境内で使用されるとき、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。コンピュータ１１０は一般に、ＷＡＮネットワーク環境内で使用されるとき、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は、内部にあっても外部にあってもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して示されているプログラムモジュール、またはその一部分を、遠隔メモリ記憶装置に格納することができる。限定ではなく例を挙げると、図１は、メモリデバイス１８１に常駐する遠隔アプリケーションプログラム１８５を示す。図のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立する他の手段を使用することができることは理解されよう。

名前空間一貫性の維持
図２は、本発明の様々な態様による、本発明が動作することができるシステムの構成要素の例示的な構成を表すブロック図である。諸構成要素は、１つまたは複数のアプリケーション２０５、アプリケーションプログラミングインターフェース（ＡＰＩ）２１０、入出力（Ｉ／Ｏ）マネージャ２１５、フィルタマネージャ２２０、ファイルシステム２２５、１つまたは複数のフィルタ２３０〜２３２を含む。

アプリケーション２０５は、ＡＰＩ２１０を介して、Ｉ／Ｏマネージャ２１５に（たとえば、関数／メソッド呼出しを介して）ファイルシステム要求を行うことができる。Ｉ／Ｏマネージャ２１５は、各要求を満たすためにどのＩ／Ｏ要求または複数のＩ／Ｏ要求を発行するべきか判定し、各Ｉ／Ｏ要求をフィルタマネージャ２２０に送ることができる。また、Ｉ／Ｏマネージャ２１０は、ファイルシステム要求に関連付けられた動作が進行した、または完了した、または中断したとき、アプリケーション２０５にデータを返すこともできる。

一実施例では、インスタンス化されるとき、フィルタマネージャ２２０において登録機構を用いて（たとえば、それらを初期化する手順の間に）登録するオブジェクトなどを含む。効率のために、各フィルタは、典型的には、処理することに関心をもつことができるファイルシステム要求について登録することになるにすぎない。そのために、各フィルタは、登録の一部として、関心をもつＩ／Ｏ要求のタイプ（たとえば、作成、読取り、書込み、クローズ、名前変更など）についてフィルタマネージャ２２０に通知する。たとえば、暗号化フィルタは、読取りＩ／Ｏおよび書込みＩ／Ｏについて登録するが、データを暗号化または解読することが必要とされない他のＩ／Ｏについては場合によっては登録しない。同様に、割当てフィルタは、オブジェクト作成およびオブジェクト書込みだけに関心をもちうる。

フィルタは、関心をもつＩ／Ｏ要求のタイプを指定することに加えて、Ｉ／Ｏのタイプのそれぞれについて、プリコールバック（ｐｒｅ−ｃａｌｌｂａｃｋ）およびポストコールバック（ｐｏｓｔ−ｃａｌｌｂａｃｋ）のために通知を受けるべきであるかどうかさらに指定することができる。プリコールバックは、Ｉ／Ｏ要求に関連付けられたデータがＩ／Ｏマネージャ２１５からファイルシステム２２５に向かって伝播するときに呼び出され、一方、ポストコールバックは、Ｉ／Ｏ要求の完了中に、Ｉ／Ｏ要求に関連付けられたデータがファイルシステム２２５からＩ／Ｏマネージャ２１５に向かって伝播するとき呼び出される。

フィルタマネージャ２２０は、各Ｉ／Ｏ要求から、フィルタ２３０〜２３２が使用するのに適した均一なフォーマットでデータ構造を作成することができる。以下、このデータ構造は、コールバックデータと呼ばれることがある。次いで、フィルタマネージャ２２０は、フィルタマネージャ２２０によって受け取られたＩ／Ｏのタイプについてコールバックを受け取るように登録されている各フィルタに対して、コールバックデータを呼び出し、渡すことができる。フィルタマネージャによって受け取られたＩ／Ｏのタイプについてコールバックを受け取るように登録されたどのフィルタも、登録済みフィルタと呼ばれることがある。

典型的には、フィルタマネージャ２２０は、特定のタイプのＩ／Ｏ要求に関連付けられたコールバックデータを、登録済みフィルタが順序付けられている順序で、順次、各登録済みフィルタに渡す。たとえば、フィルタ２３０および２３２が、読取りＩ／Ｏ要求すべてについてコールバックを受け取るように登録されており、かつ、そのような要求を処理する際にフィルタ２３０がフィルタ２３２の前となるように順序付けられる場合には、読取りＩ／Ｏを受け取った後で、フィルタマネージャ２２０は、フィルタ２３０に対してコールバックデータを呼び出し、渡すことができ、次いで、フィルタ２３０がコールバックデータを処理した後で、フィルタマネージャ２２０は、フィルタ２３２に対して（あるとすれば修正された）コールバックデータを呼び出し、渡すことができる。

フィルタは、１つまたは複数のボリュームに付随することができる。すなわち、フィルタは、呼び出しを受け取り、１つだけ、または複数のボリュームに関係するＩ／Ｏについてコールバックデータを受け取るように登録することができる。

フィルタは、それ自体のＩ／Ｏ要求を生成することができ、ついでそれを他のフィルタに渡すことができる。たとえば、アンチウィルスフィルタは、ファイルが開かれる前にファイルを読み取りたいと望む可能性がある。フィルタは、Ｉ／Ｏ要求がさらに伝播するのを止めることができ、そのＩ／Ｏ要求についてステータスコード（たとえば、成功または失敗）をレポートするようにフィルタマネージャに指令することができる。フィルタは、データをメモリに格納し、このデータをディスク上で保持することができる。一般に、フィルタは、カーネルモードプロセスまたはユーザモードプロセスによって実行することができる任意の組のアクションを実行するように作成することができ、リアクティブ（たとえば、動作する前にＩ／Ｏ要求を受け取るまで待つ）および／またはプロアクティブ（たとえば、それ自体のＩ／Ｏ要求を開始する、またはＩ／Ｏマネージャ２１５によって処理されるＩ／Ｏ要求と非同期で他のアクションを実行する）とすることができる。

一実施形態では、本発明の様々な態様による、本発明が動作することができるシステムの構成要素の他の例示的な構成を表すブロック図である図３に示されているように、フィルタを、積み重ねられた形で構成することができる。この実施形態では、フィルタ３０５〜３０７のそれぞれが、Ｉ／Ｏ要求を処理し、（修正された、または修正されていない）その要求をスタック内の別のフィルタまたは他の構成要素に渡すことができる。たとえば、読取り要求がアプリケーション２０５の１つから受け取られたことに応答して、Ｉ／Ｏマネージャ２１５は、Ｉ／Ｏ要求を発行し、この要求をフィルタ３０５に送ることができる。フィルタ３０５は、そのＩ／Ｏ要求を調べ、フィルタ３０５がそのＩ／Ｏ要求に関心をもたないことを判定し、次いで、変更されていないそのＩ／Ｏ要求をフィルタ３０６に渡す。フィルタ３０６は、そのＩ／Ｏ要求に基づいてフィルタ３０６が何らかのアクションを実行することを決定することができ、次いで、（変更された、または変更されていない）そのＩ／Ｏ要求をフィルタ３０７に渡すことができる。フィルタ３０７は、フィルタ３０７がそのＩ／Ｏ要求に関心をもたないことを判定し、そのＩ／Ｏ要求をファイルシステム２３５に渡すことができる。

ファイルシステム２３５がそのＩ／Ｏ要求に対するサービスを提供した後で、その結果をフィルタ３０７に渡す。典型的には、結果は、Ｉ／Ｏ要求が進んできた順序と逆の順序で（たとえば、まずフィルタ３０７に、次いでフィルタ３０６に、次いでフィルタ３０５に）進む。フィルタ３０５〜３０７のそれぞれは、その結果を調べることができ、そのフィルタがその結果に関心をもつかどうか判定し、それに基づいて、（変更された、または変更されていない）その結果を別のフィルタまたは構成要素に渡す前に、アクションを実行することができる。

本発明の他の実施形態では、本発明の様々な態様による、本発明が動作することができるシステムの構成要素の他の例示的な構成を表すブロック図である図４に示されているように、フィルタを、積み重ねられた／管理された形で構成することができる。この構成では、フィルタは、フィルタマネージャに関連付けられるものもあれば、関連付けられないものもある。フィルタマネージャ２２０は、他のフィルタ（たとえば、フィルタ３０５および３０７）と共にスタック内に配置される。

フィルタは、本発明の精神または範囲から逸脱することなく、多数の他の構成で実施することができることは、容易に理解されよう。いくつかの実施形態では、フィルタは、アプリケーションとファイルシステムの間でＩ／Ｏを調べる、および、そのＩ／Ｏを変更、完了、または中断すること、またはそれに基づいて他のアクションを実行することが可能である任意のオブジェクトを含む。

図２に戻ると、ファイルシステム２３５は、アプリケーション２０５がその上で実行するマシンまたは複数のマシンにローカルで、または遠隔で位置することができる１つまたは複数のボリュームを含むことができる。

いくつかのフィルタは、あるディレクトリ内でファイルを監視する。たとえば、割当てフィルタは、特定のディレクトリに対して割当てを実施することができる。他の例として、データ画面フィルタは、あるディレクトリ内で、あるタイプのファイル（たとえば、ＭＰ３、ＪＰＧなど、ある拡張子によって示されて著作権で保護される可能性があるファイル）の作成を拒否することができる。これらのフィルタは、関連するディレクトリを識別する名前空間を含むことができる。

あるファイルシステム要求（たとえば、名前変更および削除）は、フィルタによって監視されるオブジェクトについて、ファイルシステム名前空間を変更することができる。たとえば、割当てフィルタは、Ｃ：＼ＤＩＲ＼ＱＵＯＴＡと呼ばれるオブジェクトに対して１ギガバイトの割当てを実施するように構成することができる。オブジェクトの名前と、そのオブジェクトに適用可能な割当ては、不揮発性ストレージ上で保持されるメタデータファイルに格納することができる。アプリケーションは、オブジェクトＣ：＼ＤＩＲからＣ：＼ＤＩＲ２に名前変更することも、Ｃ：＼ＤＩＲ＼ＱＵＯＴＡをＣ：＼ＱＵＯＴＡに移動することもできる。引き続きＱＵＯＴＡオブジェクトに対して割当てを実施するために、割当てフィルタは、名前変更を監視し、名前変更により、割当てフィルタが割当てを実施しつつあるオブジェクトが影響を受けるたびに、そのメタデータファイルを更新する。

いくつかのオペレーティングシステムでは、名前変更動作により、オブジェクトが名前変更される、かつ／またはそのオブジェクトが移動される可能性がある。したがって、名前変更動作を監視することにより、フィルタは、名前の変更、オブジェクトの移動、またはその両方を捕捉することができる。ファイルの名前変更とファイルの移動が別々の動作であるオペレーティングシステムでは、フィルタは、ファイルシステムの名前空間との名前空間一貫性を維持するために、これらの両動作を監視することを必要とする場合がある。

さらに、アプリケーションは、オブジェクト、たとえばＣ：＼ＤＩＲまたはＣ：＼ＤＩＲ＼ＱＵＯＴＡを削除することができる。削除されたオブジェクトを監視することを回避し、既存のオブジェクトが削除され、同じ名前を有する新しいオブジェクトがその位置で再作成されたときポリシーを実施しないために、また、そのようなオブジェクトを監視する際に使用されるメタデータのサイズを削減するために、フィルタは、削除を監視し、それに応じてそのメタデータを更新することができる。

図５は、本発明の様々な態様による、ポリシーが適用されているオブジェクトを監視するために使用することができるデータ構造を表すブロック図である。本明細書で述べるごとく、監視されるオブジェクトは、ディレクトリ、ファイル、ファイルシステム上で記憶することができる任意のものなどを含む。

データ構造は、注目の各オブジェクトについてノードを含み、しばしばプリフィクスツリーと呼ばれることがある。表されている例示的なオブジェクトは、ルートディレクトリ「＼」、＼ＤＩＲ１、＼ＤＩＲ１＼ＱＵＯＴＡ１、＼ＤＩＲ１＼ＱＵＯＴＡ１＼ＱＵＯＴＡ２、＼ＤＩＲ２、＼ＤＩＲ２＼ＤＩＲ３、および＼ＤＩＲ２＼ＤＩＲ３＼ＱＵＯＴＡ３を含む。オブジェクト＼ＤＩＲ１＼ＱＵＯＴＡ１、＼ＤＩＲ１＼ＱＵＯＴＡ１＼ＱＵＯＴＡ２、および＼ＤＩＲ２＼ＤＩＲ３＼ＱＵＯＴＡ３には、それぞれに適用されるポリシーＰ１、Ｐ２、Ｐ３を有している。ポリシーは、オブジェクトとその子孫（たとえば、サブディレクトリ）によって消費されるディスクスペースに対する割当て、オブジェクトとその子孫内で許されるファイル、オブジェクトとその子孫に関連して何が許され、かつ／または許されないか、などを含むことができる。注目のオブジェクトがファイルシステム上で名前変更または削除されたとき、図５に示されているデータ構造を更新することが必要とされる場合がある。そのような更新は、下記でより詳しく述べるように、ノードを削除すること、追加のノードを追加すること、およびノードの内容を変更することを含むことができる。

一般に、オブジェクトを名前変更または削除することにより、そのオブジェクトをデータ構造内で見つけること、またはポリシーの適用が影響を受けることになる場合、そのオブジェクトは注目されるものである。たとえば、＼ＤＩＲ２とそのサブディレクトリが削除されたならば、ポリシーＰ３を＼ＤＩＲ２＼ＤＩＲ３＼ＱＵＯＴＡ３に適用することは、もはや必要とされないはずである。さらに、ノードＤＩＲ２、ＤＩＲ３、ＱＵＯＴＡ３は、ポリシーＰ３を割り当てることをもはや必要としないはずであり、スペースを保存し、任意の残りのポリシーについてルックアップ時間を減らすために削除することができるはずである。

他の例として、＼ＤＩＲ１＼ＱＵＯＴＡ１＼ＱＵＯＴＡ２がファイルシステム上で＼ＱＵＯＴＡ５に名前変更された場合、これは、データ構造内でその新しいオブジェクトを見つけることに影響を及ぼす可能性がある。これは、フィルタが、特定の動作にポリシーを適用する前に、ポリシーが確立済みである任意のオブジェクトにその動作が影響を及ぼす可能性があるかどうか知ることを必要とするので、重要である。（たとえば、フィルタが、特定の動作に対してポリシーを実施することを必要とするかどうか判定することができるように）データ構造内で新しいオブジェクトを見つけるために、新しいノードを作成し、その新しいオブジェクトに関連付けることができ、次いで、旧ノードＱＵＯＴＡ２に関連付けられたポリシー（たとえば、Ｐ２）をその新しいノードにコピーすることができ、次いで、旧ノードＱＵＯＴＡ２を削除することができる。次いで、ポリシーＰ２をその新しいオブジェクトについて実施することができる。オブジェクトに対する変更に応答して追加および削除することについては、図８〜１０に関連してより詳しく述べる。

アプリケーション（たとえば、サービスまたは他のもの）は、どのオブジェクトが、それらに関連付けられているポリシーを有するかフィルタに伝えることができる。アプリケーションは、そのようなオブジェクトのリストを提供することができ、要求どおりポリシーを追加および／または削除することができる。フィルタは、そのようなリストまたは命令を受け取った後で、新しいデータ構造を作成する、または注目のオブジェクトを捕らえるために既存のデータ構造を修正することができる。

データ構造は、ブート時、またはそのデータ構造を使用するフィルタのインスタンス化の際に再構築することができる。これは、不揮発性ストレージ（たとえば、ディスク）上で保持される上述のメタファイルを使用して行うことができる。

データ構造は、複数のフィルタ間で共用することができる。たとえば、２つ以上のフィルタが、名前変更または削除することができるオブジェクトに対してポリシーを実施することができる。この２つ以上のフィルタは、各フィルタについてデータ構造の別々のコピーを維持するのではなく、データ構造を共有することができる。１つまたは複数のフィルタを指定し、データ構造をファイルシステムに同期したまま保つことができる。

さらに、フィルタは、データ構造を共有することができるが、同じオブジェクトすべてを監視することを望まない場合がある。そのために、どのノードに各フィルタが関心をもつかを示す追加のデータを維持することができる。

図６は、本発明の様々な態様による、注目のオブジェクトについて、フィルタ名前空間とフィルタシステム名前空間の間で一貫性を維持するために行うことができる動作を全体的に表す流れ図である。ブロック６０５でプロセスが開始する。ブロック６１０では、フィルタが、注目のＩ／Ｏ動作を受ける。管理されるフィルタの場合には、フィルタは、受けたタイプのＩ／Ｏ動作を受け取るように、先に登録されている可能性がある。積み重ねられたフィルタ（ｓｔａｃｋｅｄ ｆｉｌｔｅｒｓ）の場合には、フィルタは、そのＩ／Ｏがファイルシステム名前空間に影響を及ぼす可能性があるものであることを判定することができる。一実装では、ファイルシステム名前空間に影響を及ぼす可能性があるいくつかのＩ／Ｏ動作には、名前変更および削除が含まれる。

ブロック６１５では、そのＩ／Ｏ動作が注目のオブジェクトに関係するかどうかについて判定が行われる。関係がある場合、処理はブロック６２５に分岐し、そうでない場合には、処理がブロック６２０に分岐し、そこでプロセスが戻る（リターンする）。図５を参照すると、注目のオブジェクトは、データ構造の任意のノードによって表されるオブジェクトである。次いで、フィルタは、注目のＩ／Ｏ動作に関連付けられたデータを受け取った後で、データ構造に対してルックアップを行い、そのＩ／Ｏ動作がその中にいずれかのノードを含むかどうか判定することができる。含まない（たとえば、ルックアップが失敗した）場合、フィルタは戻ることができる。

ブロック６２５では、そのＩ／Ｏ動作が名前変更動作であるかどうかについて判定が行われる。名前変更動作である場合、処理はブロック６３０に分岐し、そうでない場合には、処理はブロック６３５に分岐する。他の実施形態では、ブロック６１５および６１０に関連付けられたアクションが逆になる。すなわち、まずＩ／Ｏ動作が注目のオブジェクトを含むかどうかについて判定が行われ、次いで、そのＩ／Ｏ動作が注目されるものであるかどうかについて判定が行われる。この実施形態では、Ｉ／Ｏが注目のオブジェクトを含まない場合、またはそのＩ／Ｏが注目のＩ／Ｏでない場合、プロセスは戻る。

ブロック６３０では、図７〜１０に関連してより詳しく述べるように、フィルタ名前空間が必要に応じて更新される。ブロック６３２では、図１３に関連してより詳しく述べるように、オブジェクトに関連付けられたストリームコンテキストが存在する場合、そのストリームコンテキストが更新される。ストリームコンテキストは、オブジェクトに関する情報を格納し取り出すことができるデータを含む。ストリームコンテキストは、たとえば、オブジェクトが削除のためにマークされているとき、そのオブジェクトについて作成することができる。オブジェクトは、削除のためにマークすることができるが、削除される前に名前変更することができる。名前変更を通じてオブジェクトの名前を追跡するために、オブジェクトの新しい名前がストリームコンテキストに格納される。オブジェクトが名前変更されるたびに、オブジェクトの新しい名前を含むようにストリームコンテキストが更新される。次いで、オブジェクトが最後に削除されたとき、フィルタは、ストリームコンテキスト内で削除済みオブジェクトの最新の名前をルックアップし、適切な、ノードまたは複数のノードを、フィルタの名前空間から削除する。

ブロック６３５では、その動作が削除関連動作であるかどうかについて判定が行われる。削除関連動作である場合、処理はブロック６４０に分岐し、そうでない場合には、処理はブロック６４５に分岐する。図１１に関連してより詳しく述べるように、削除関連動作は、クローズ時に削除する作成（ｃｒｅａｔｅ ｆｏｒ ｄｅｌｅｔｅ ｏｎ ｃｌｏｓｅ）動作、設定処分（ｓｅｔ ｄｉｓｐｏｓｉｔｉｏｎ）動作、またはクリーンナップ動作を含むことができる。ブロック６４０では、図１０に関連してより詳しく述べるように、フィルタ名前空間が必要に応じて更新される。

ブロック６４５では、任意の他のフィルタアクションを実行することができる。たとえば、割当てフィルタは、Ｉ／Ｏ要求が続行することを許可しない、または許可することによって、割当てを実施することができる。いくつかの実装では、ブロック６４５に関連付けられたアクションは、ブロック６１０の直後に行われる。これにより、フィルタで動作を失敗させ、任意のオブジェクトの変更を停止することを可能にすることができる。ブロック６２０でプロセスが戻る。図６に関連して述べられているプロセスは、注目のＩ／Ｏ動作を受けるたびに繰り返すことができる。

図７は、本発明の様々な態様による、名前変更動作を受けたとき行うことができる、図６のブロック６３０に対応するアクションを全体的に表す流れ図である。ブロック７０５でプロセスが開始する。ブロック７１０では、名前変更動作がプリコールバック段階（ｐｈａｓｅ）にあるか、それともポストコールバック段階にあるかに関して判定が行われる。動作がプリコールバック段階にある場合（すなわち、Ｉ／Ｏ要求がファイルシステムに伝播する前）、処理はブロック７１５に分岐し、そうでない場合には、動作がポストコールバック段階にあるとき、処理はブロック７３０に分岐する。本質的には、プロセスは、動作が成功するまで待ってから、データ構造を更新する。

ブロック７１５では、コールバックコンテキストが割り振られ、動作に関連付けられる。コールバックコンテキストは、任意のデータを含むことができ、動作に関するデータをポストコールバック段階に渡すための手段を提供する。ポストコールバック段階が特定の動作について発生したとき、その動作に関連付けられたコールバックコンテキストにアクセスすることができる。

ブロック７２０では、動作が実行される前のオブジェクトの名前（すなわち、旧名）が、コールバックコンテキストに格納される。ブロック７２５では、本質的には、動作がファイルシステム上で実行された後、Ｉ／Ｏ結果がアプリケーションに返る前に呼び出されることを望むことをフィルタが示すことを意味する動作後（ｐｏｓｔ−ｏｐｅｒａｔｉｏｎ）コールバックが実行される。

ブロック７３０での動作後段階では、動作が失敗したかどうかについて判定が行われる。失敗した場合、処理はブロック７５０に分岐し、そうでない場合には、処理はブロック７３５に分岐する。動作が失敗した場合、データ構造を更新することは必要とされない。

ブロック７３５では、オブジェクトの旧名が、コールバックコンテキストから取り出される。この旧名は、フィルタ名前空間を維持するデータ構造内でノードを見つけるために使用される。ブロック７４０では、新しいオブジェクト名および／またはオブジェクトパスを含むことができるオブジェクトの新しい名前について、ファイルシステムが照会される。ブロック７４５では、図８に関連してより詳しく述べるように、データ構造が更新される。ブロック７５０では、コールバックコンテキストが解放される。ブロック７５５でプロセスが戻る。

図８は、本発明の様々な態様による、データ構造を更新する際に行うことができる、図７のブロック７４５に対応するアクションを全体的に表す流れ図である。ブロック８０５でプロセスが開始する。ブロック８１０では、オブジェクトが移動されているかどうかについて判定が行われる。移動されている場合、処理はブロック８１５に分岐し、そうでない場合には、処理はブロック８３０に分岐する。オブジェクトが移動されている場合、旧ノードを削除し、新しいノードを作成し、ブロック８１５、８２０、８２５によって示されているように、フィルタ名前空間およびポリシーを更新することができる。オブジェクトの名前だけが変更され、そのパスが変更されていない場合、ノード内に示されているオブジェクトの名前を、ブロック８３０によって示されているように新しいオブジェクト名に変更することができる。

ブロック８３５では、移動されたノードの子孫ノードを、必要に応じて更新することができる。一実施例では、完全パスおよびオブジェクト名が、各ノードに格納される。たとえば、図５を参照すると、ＱＵＯＴＡ２ノードは、＼ＤＩＲ１＼ＱＵＯＴＡ１＼ＱＵＯＴＡ２を格納することができる。これは、実行を速めるために、または他の理由で行うことができる。あるノードのオブジェクト名および／またはパスが変更されるとき、そのノードの子孫であるノードのそれぞれを更新し、その変更されたノードに関連付けられた新しいオブジェクト名および／またはパスを含めることができる。他の実施例（たとえば、完全パスおよびオブジェクト名がノードに格納されず、子孫ノード内で更新することを必要としない場合）では、ブロック８３５を省くことができる。

ブロック８４０でプロセスが戻る。

図９は、本発明の様々な態様による、オブジェクトが移動されるときノードを追加する際に行うことができる、図８のブロック８１５に対応するアクションを全体的に表す流れ図である。ブロック９０５でプロセスが開始する。ブロック９１０では、オブジェクトの新しいパスの第１の構成要素が選択される。あるパスで使用されているとき、構成要素は、そのオブジェクトの先祖オブジェクトに対応するパスの一部分を指し、ルートディレクトリを含むことができる。たとえば、＼ＤＩＲ１＼ＱＵＯＴＡ１＼ＱＵＯＴＡ２の構成要素は、ルート（すなわち「＼」）、ＤＩＲ１、ＱＵＯＴＡ１、ＱＵＯＴＡ２である。第１の構成要素は、ルートである。

ブロック９１５では、選択された構成要素に対応するノードが存在するかどうかについて判定が行われる。存在する場合、新しいノードを作成することが必要とされないので、処理がブロック９２５に分岐し、そうでない場合には、処理はブロック９２０に分岐する。ブロック９２０では、その構成要素に対応する新しいノードが作成される。

ブロック９２５では、現在選択されている構成要素が新しいパスの最後の構成要素であるかどうかについて判定が行われる。そうである場合、処理はブロック９０５に分岐し、処理が戻る。そうでない場合には、処理はブロック９３０に分岐し、次の構成要素が選択され、ブロック９１５〜９２５に関連付けられたアクションを、最後の構成要素が処理されるまで繰り返すことができる。図９に関連して述べられている処理は、本質的には、まだデータ構造内に存在しない新しいパス内の任意の構成要素についてノードを含むようにデータ構造を修正することを理解されよう。

図１０は、本発明の様々な態様による、旧オブジェクト名に関連付けられたプリフィクスノードを除去するためにデータ構造を更新するとき行うことができる、図８のブロック８２５に対応するアクションを全体的に表す流れ図である。一般に、ノードがデータ構造内で新しい位置に移動されるとき、もはや必要でないノードすべてがデータ構造から除去される。ノードは、関連付けられたポリシーを有する子孫を持たず、かつノード自体がそれに関連付けられたポリシーを有していない場合、もはや必要ないものとなる。

プロセスはブロック１００５で開始する。ブロック１０１０では、旧オブジェクトに関連付けられたノードが選択される。ブロック１０１５では、先に新しいノードにすでにコピー済みであるため、旧ノードのポリシーが除去される。ブロック１０２０では、現在選択されているノードがそれに関連付けられているポリシーを有しているかどうかについて判定が行われる。関連付けられている場合、処理はブロック１０４５に分岐し、そうでない場合には、処理はブロック１０２５に分岐する。

ブロック１０２５では、ノードがいずれかの子を有するかどうかについて判定が行われる。子を有する場合、処理はブロック１０４５に分岐し、そうでない場合には、処理はブロック１０３０に分岐する。ノードは、ポリシーおよびその先祖を有するオブジェクトについて維持され、そうでない場合には維持されないため、ノードがいずれかの子を有する場合、これは、ノードの子孫の少なくとも１つがポリシーに関連付けられることを示す。たとえば、ポリシーを有していなかったノードが２つの子を有し、その子の一方が、もはやそのノードの子孫にならないように名前変更されたならば、そのノードは、第２の子もまた削除されるまで削除されないことになる。

ブロック１０３０では、もはや必要とされないのでノードが削除される。ブロック１０３５では、そのノードが親を有するかどうかについて判定が行われる。親を有する場合、処理はブロック１０４０に分岐し、その親が選択される。処理は、ブロック１０４０からブロック１０２０に継続し、ブロック１０２０〜１０３５に関連付けられたアクションを繰り返すことができる。これらのアクションは、事実上、再帰的にデータ構造を登り、それ自体ポリシーに関連付けられる、またはポリシーに関連付けられた子孫を有するノードを見つけるまで、ノードを削除することは理解されよう。

ブロック１０４５でプロセスが戻る。

図６〜１０の流れ図は、ファイルシステムに名前変更が行われたとき名前空間データ構造を一貫したものとなるように更新することができる１つの方法を表し、また、名前変更中に名前空間データ構造をファイルシステムの名前空間と一貫した状態で保つことを、本発明の精神および範囲から逸脱することなく様々な方法で実施することができることは理解されよう。

図１１は、本発明の様々な態様による、削除関連動作中にフィルタ名前空間とファイルシステム名前空間の間で一貫性を維持するために行うことができる、図６のブロック６４０に対応するアクションを全体的に表す流れ図である。ブロック１１０５でプロセスが開始する。

ブロック１１１０では、動作が、クローズ時に削除する作成動作であるかどうかについて判定が行われる。そうである場合、処理はブロック１１１５に分岐し、そうでない場合には、処理はブロック１１３０に分岐する。作成動作は、オブジェクトを作成する、または、すでに存在するオブジェクトを開くことができる。オブジェクトは、クローズ時に削除するように作成することができる。オブジェクトが、クローズ時に削除するように作成されたとき、これは、そのオブジェクトが閉じられた後で、そのオブジェクトを削除するべきであることを意味する。すなわち、オブジェクトは、そのオブジェクトに対するハンドルを有するプロセスすべてがそのハンドルを閉じるまで、作成、存在、存続することができる。ハンドルすべてが閉じられた後で、そのオブジェクトは削除される。ブロック１１１５では、その作成のためのアクションが、図１２に関連してより詳しく述べるように実行される。

ブロック１１３０では、動作が設定処分動作（ｓｅｔ ｄｉｓｐｏｓｉｔｉｏｎ ｏｐｅｒａｔｉｏｎ）であるかどうかについて判定が行われる。そうである場合、処理はブロック１１３５に分岐し、そうでない場合には、処理はブロック１１４０に分岐する。一実施例では、オブジェクトは、このオブジェクトに関連付けられる、このオブジェクトに対するハンドルすべてを閉じた後でそのオブジェクトを削除するべきであるかどうかを示すフラグを有することができる。このフラグは、設定する（すなわち、オブジェクトを削除するべきであることを示す）ことも、クリアする（すなわち、オブジェクトを削除するべきでないことを示す）こともできる。さらに、フラグは、オブジェクトに対するオープンハンドルを有する各プロセスによって設定またはクリアすることができる。したがって、あるプロセスがフラグを設定し、結局別のプロセスによってクリアされる可能性がある。オブジェクトは、そのオブジェクトに対するハンドルを有する最後のプロセスがハンドルを閉じた時点で、フラグの処分（たとえば、設定されている、またはクリアされている）に応じて残るか、または削除される。ブロック１１３５では、オブジェクトの処分を設定することに関係するアクションが、図１４に関連してより詳しく述べるように実行される。

ブロック１１４０では、動作がクリーンナップ動作であるかどうかについて判定が行われる。そうである場合、処理はブロック１１４５に分岐し、そうでない場合には、処理はブロック１１５５に分岐する。クリーンナップ動作は、プロセスがオブジェクトに対するハンドルを閉じるたびに発行することができる。しかし、先に述べたように、オブジェクトは、そのオブジェクトに対するハンドルを有する最後のプロセスがハンドルを閉じるまで、実際には削除されない可能性がある。最後のプロセスがオブジェクトを閉じた後ですら、たとえば、最後のクローズの時点で、オブジェクトを削除するためのフラグが、クローズ時にそのオブジェクトを削除するべきでないことを示す場合、オブジェクトは削除されない可能性がある。ブロック１１４５では、クリーンナップアクションが、図１５に関連してより詳しく述べるように実行される。

ブロック１１５５でプロセスが戻る。図１１に関連して述べられているプロセスは、フィルタが注目のオブジェクトについて削除関連Ｉ／Ｏ動作を受けるたびに繰り返すことができる。

図１２は、本発明の様々な態様による、クローズ時に削除する作成動作を受けたとき行うことができる、図１１のブロック１１１５に対応するアクションを全体的に表す流れ図である。ブロック１２０５でプロセスが開始する。

ブロック１２１０では、動作が動作前（ｐｒｅ−ｏｐｅｒａｔｉｏｎ）段階にあるかどうかについて判定が行われる。動作前段階にある場合、処理はブロック１２１５に分岐し、そうでない場合には、処理はブロック１２２０に分岐する。

ブロック１２１５では、動作後コールバックが実行され、その結果、フィルタは、その動作の動作後段階中にコールバックを受け取ることになる。ブロック１２２０では、動作が失敗したかどうかについて判定が行われる。失敗した場合、処理はブロック１２４０に分岐し、そうでない場合には、処理はブロック１２２５に分岐する。

ブロック１２２５では、ストリームコンテキストが（まだ存在しない場合）割り振られ、オブジェクトに関連付けられる。ブロック１２３０では、オブジェクト名がストリームコンテキストに格納される。ブロック１２３５では、削除フラグが、ストリームコンテキスト内で更新される。クローズ時に削除するように作成されたオブジェクトの場合、フラグは、そのオブジェクトに対するハンドルすべてが閉じられたとき、そのオブジェクトが削除されることを示すことができる。このタイプのフラグは、後続のプロセスによって修正されない可能性がある。そのオブジェクトに対するハンドルすべてが閉じられたとき、クローズ時に削除するように開かれた（オープンされた）オブジェクトが削除される。

クローズ時に削除するように開かれていないオブジェクトの場合、そのオブジェクトをクローズ時に削除するべきである、または削除するべきでないことを示すために、（設定処分動作を介して）フラグを設定またはクリアすることができる。次いで、そのフラグは、後続の設定処分動作によって変更される可能性がある。ハンドルすべてが閉じられた後でオブジェクトが削除されるかどうかは、そのオブジェクトに対する最後のハンドルが閉じられたとき、フラグの状態によって決まる。

ブロック１２４０でプロセスが戻る。

図１３は、本発明の様々な態様による、名前変更動作を受けたとき行うことができる、図６のブロック６３２に対応するアクションを全体的に表す流れ図である。ブロック１３０５でプロセスが開始する。

ブロック１３１０では、動作が動作前段階にあるかどうかについて判定が行われる。動作前段階にある場合、処理はブロック１３３０に分岐し、そうでない場合には、処理はブロック１３１５に分岐する。

ブロック１３３０では、動作後コールバックが実行され、その結果、フィルタは、その動作の動作後段階中にコールバックを受け取ることになる。ブロック１３１５では、動作が失敗したかどうかについて判定が行われる。失敗した場合、処理はブロック１３３５に分岐し、そうでない場合には、処理はブロック１３２０に分岐する。

ブロック１３２０では、オブジェクトに関連付けられるストリームコンテキストが存在するかどうかについて判定が行われる。存在する場合、処理は１３２５に分岐し、そうでない場合には、処理はブロック１３３５に分岐する。ストリームコンテキストは、たとえば、そのオブジェクトがクローズ時に削除するように開かれておらず、そのオブジェクトをクローズ時に削除するべきかどうかを示すフラグ上で処分が設定またはクリアされていない場合、存在しない可能性がある。

ブロック１３２５では、オブジェクトが変更を受けている名前を反映するために、名前がストリームコンテキスト内で更新される。これは、たとえば、名前変更が任意のノードに影響を及ぼすことになるかどうか、後で判定する際に有用である。

ブロック１３３５でプロセスが戻る。

図１４は、本発明の様々な態様による、設定処分動作を受けたとき行うことができる、図１１のブロック１１３５に対応するアクションを全体的に表す流れ図である。ブロック１４０５でプロセスが開始する。

ブロック１４１０では、動作が動作前段階にあるかどうかについて判定が行われる。動作前段階にある場合、処理はブロック１４１５に分岐し、そうでない場合には、処理はブロック１４２０に分岐する。

ブロック１４１５では、動作後コールバックが実行され、その結果、フィルタは、その動作の動作後段階中にコールバックを受け取ることになる。ブロック１４２０では、動作が失敗したかどうかについて判定が行われる。失敗した場合、処理はブロック１４４０に分岐し、そうでない場合には、処理はブロック１４２５に分岐する。

ブロック１４２５では、オブジェクトに関連付けられるストリームコンテキストが存在するかどうかについて判定が行われる。存在する場合、処理は１４３５に分岐し、そうでない場合には、処理はブロック１４３０に分岐し、ストリームコンテキストが作成され、そのオブジェクトの名前がそこに格納される。ストリームコンテキストは、そのオブジェクトに関連付けられる。

ブロック１４３５では、そのオブジェクトの削除処分（ｄｅｌｅｔｅ ｄｉｓｐｏｓｉｔｉｏｎ）を反映するために、削除フラグが更新される。前述のように、プロセスは、フラグを設定し、そのオブジェクトをクローズ時に削除するべきであることを示すことも、フラグをクリアし、そのダイレクタ（ｄｉｒｅｃｔｏｒ）をクローズ時に削除するべきでないことを示すこともできる。ブロック１４４０でプロセスが戻る。

図１５は、本発明の様々な態様による、クリーンナップ動作を受けたとき行うことができる、図１１のブロック１１４５に対応するアクションを全体的に表す流れ図である。ブロック１５０５でプロセスが開始する。

ブロック１５１０では、動作が動作前段階にあるかどうかについて判定が行われる。動作前段階にある場合、処理はブロック１５１５に分岐し、そうでない場合には、処理はブロック１５２０に分岐する。

ブロック１５１５では、動作後コールバックが実行され、その結果、フィルタは、その動作の動作後段階中にコールバックを受け取ることになる。ブロック１５２０では、動作が失敗したかどうかについて判定が行われる。失敗した場合、処理はブロック１５５０に分岐し、そうでない場合には、処理はブロック１５２５に分岐する。

ブロック１５２５では、オブジェクトに関連付けられるストリームコンテキストが存在するかどうかについて判定が行われる。存在する場合、処理は１５３０に分岐し、そうでない場合には、処理はブロック１５５０に分岐する。ブロック１５３０では、そのオブジェクトがフィルタとって注目のオブジェクトであるかどうかについて判定が行われる。そうである場合、処理はブロック１５３５に分岐し、そうでない場合には、処理はブロック１５５０に分岐する。

ブロック１５３５では、削除フラグが、削除するように設定されているかどうか、または、そのオブジェクトが、クローズ時に削除するように開かれているかどうかについて判定が行われる。これらの条件のどちらかが満たされた場合、処理はブロック１５４０に分岐し、そうでない場合には、処理はブロック１５５０に分岐する。一実装では、オブジェクトがクローズ時に削除するように開かれたとき、そのオブジェクトがクローズ時に削除されないことを後で示さないことができる。

ブロック１５４０では、オブジェクトが削除されるかどうかについて判定が行われる。多数のプロセスがオブジェクトを開くことができ、そのオブジェクトは、プロセスすべてがそのオブジェクトに対するハンドルを閉じた後で削除されるにすぎないため、他の基準すべてが満たされてもオブジェクトが削除されない可能性がある。本発明の一実施形態では、オペレーティングシステムは、（フィルタがそれ自体のためにチェックするのではなく）いつオブジェクトが削除されたかフィルタに通知することができる。そのような実施形態では、図１５に関連して述べられている方法は、そのオブジェクトが注目のものであるかどうか判定すること、および、必要に応じてノードを削除することを含むことができる。

ブロック１５４５では、ノードと任意の関連ノードが、必要に応じて削除される。そのノードが、図５に関連して述べられているデータ構造内の他のノードの先祖である場合、その他のノードもまた削除される。さらに、図１０に関連して述べられているものと同様のアクションを実行し、そのノードの先祖ノードである、もはや必要とされないノードを削除することができる。ブロック１５５０でプロセスが戻る。

図１１〜１５に関連して述べられているアクションは、本発明の精神または範囲から逸脱することなく、他のアクションと置き換えることができ、オペレーティングシステムが動作する方法に応じて、異なる順序で実行することができる。たとえば、いくつかのオペレーティングシステムは、ファイルに対するハンドルすべてが閉じられた後でファイルを削除するべきかどうか示すためのフラグを有していない可能性がある。逆に、そのようなオペレーティングシステムは、オブジェクトを削除するために別個の削除動作を提供することができる。そのようなオペレーティングシステムでは、削除するために変更を検出するための方法は、いつオブジェクトが削除されるか監視すること、および、そのオブジェクトに関連付けられるノード（があればそれ）を削除することを含むことができる。

図１２〜１４の動作後コールバックの実行は、動作後コールバックがデフォルトで行われる実装において省くことができる。

前述の詳細な説明からわかるように、ファイルシステムとの名前空間一貫性を維持するための方法およびシステムが提供される。本発明は様々な修正形態および代替の構成が可能であるが、そのいくつかの例示の実施形態が図面に示され、上記で詳しく述べられている。しかし、本発明を開示されている特定の形態に限定することを意図しておらず、それどころか本発明は、本発明の精神および範囲内に入るあらゆる修正形態、代替の構成、均等物を包含するものとすることを理解されたい。

本発明を組み込むことができるコンピュータシステムを表すブロック図である。 本発明の様々な態様による、本発明が動作することができるシステムの構成要素の例示的な構成を表すブロック図である。 本発明の様々な態様による、本発明が動作することができるシステムの構成要素の他の例示的な構成を表すブロック図である。 本発明の様々な態様による、本発明が動作することができるシステムの構成要素の他の例示的な構成を表すブロック図である。 本発明の様々な態様による、ポリシーが適用されているオブジェクトを監視するために使用することができるデータ構造を表すブロック図である。 本発明の様々な態様による、注目のオブジェクトについて、フィルタ名前空間とフィルタシステム名前空間の間で一貫性を維持するために行うことができる動作を全体的に表す流れ図である。 本発明の様々な態様による、名前変更動作を受けたとき行うことができる、図６のブロック６３０に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、データ構造を更新する際に行うことができる、図７のブロック７４５に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、オブジェクトが移動されるときノードを追加する際に行うことができる、図８のブロック８１５に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、旧オブジェクト名に関連付けられたプリフィクスノードを除去するためにデータ構造を更新するとき行うことができる、図８のブロック８２５に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、削除関連動作中にフィルタ名前空間とファイルシステム名前空間の間で一貫性を維持するために行うことができる、図６のブロック６４０に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、クローズ時に削除する作成動作を受けたとき行うことができる、図１１のブロック１１１５に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、名前変更動作を受けたとき行うことができる、図６のブロック６３２に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、設定処分動作を受けたとき行うことができる、図１１のブロック１１３５に対応するアクションを全体的に表す流れ図である。 本発明の様々な態様による、クリーンナップ動作を受けたとき行うことができる、図１１のブロック１１４５に対応するアクションを全体的に表す流れ図である。

符号の説明

１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 取り外し不能不揮発性メモリインターフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ 取り外し可能不揮発性メモリインターフェース
１６０ ユーザ入力インターフェース
１６１ マウス
１６２ キーボード
１７０ ネットワークインターフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ 広域ネットワーク
１８０ 遠隔コンピュータ
１８５ 遠隔アプリケーションプログラム
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺機器インターフェース
１９６ プリンタ
１９７ スピーカ

Claims (21)

1. フィルタの名前空間とファイルシステムの名前空間との間で一貫性を維持する方法を実行するためのコンピュータ実行可能命令を有するコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令は、実行されると、
   前記ファイルシステムのオブジェクトについてのＩ／Ｏ要求を受け取るステップと、
   前記受け取ったＩ／Ｏ要求に基づいて、前記オブジェクトが、前記フィルタに関連付けられた名前空間内にあるオブジェクトであるかどうかを判定するステップと、
   前記オブジェクトが前記フィルタに関連付けられた名前空間内にあるオブジェクトである場合に、前記Ｉ／Ｏ要求が前記オブジェクトの名前変更動作であるかどうかを判定するステップと、
   前記Ｉ／Ｏ要求が前記オブジェクトの名前変更動作である場合に、前記受け取ったＩ／Ｏ要求に基づいて前記フィルタの名前空間を維持するデータ構造内の前記オブジェクトの名前を変更することによって、前記フィルタに関連付けられた前記名前空間を更新するステップと
   を備える方法を実行することを特徴とするコンピュータ可読記憶媒体。
2. 前記名前変更動作は、前記オブジェクトを、前記ファイルシステム内の異なる位置に移動させることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
3. 前記名前変更動作は、前記オブジェクトに関連付けられた名前を変更させることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
4. 前記Ｉ／Ｏ要求は、削除動作を含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
5. 前記削除動作は、前記オブジェクトに関連付けられたハンドルすべてが閉じられた後で前記オブジェクトが削除されることを示すためにフラグを設定するステップを含むことを特徴とする請求項４に記載のコンピュータ可読記憶媒体。
6. 前記オブジェクトが削除されるべきでないことを示すために、前記フラグをクリアするステップをさらに含むことを特徴とする請求項５に記載のコンピュータ可読記憶媒体。
7. 前記Ｉ／Ｏ要求は、クリーンナップ動作を含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
8. プロセスが前記オブジェクトに対するハンドルを閉じるたびに、前記クリーンナップ動作が発行されることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
9. 前記オブジェクトが、前記フィルタに関連付けられた名前空間内にあるオブジェクトであることを判定するステップは、前記フィルタの名前空間を維持するデータ構造内で前記オブジェクトの名前を探索するステップを含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
10. 前記データ構造が階層で構成されることを特徴とする請求項９に記載のコンピュータ可読記憶媒体。
11. 前記データ構造は、関連付けられたポリシーを有する各オブジェクトについてノードを含むことを特徴とする請求項９に記載のコンピュータ可読記憶媒体。
12. 前記データ構造は、関連付けられたポリシーを有する各オブジェクトの各先祖についてノードを含むことを特徴とする請求項１１に記載のコンピュータ可読記憶媒体。
13. 前記先祖は、前記オブジェクトが常駐するディレクトリを含むことを特徴とする請求項１２に記載のコンピュータ可読記憶媒体。
14. 前記オブジェクトは、前記ファイルシステムのディレクトリを含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
15. 前記オブジェクトは、前記ファイルシステムのファイルを含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
16. 前記Ｉ／Ｏ要求は、前記オブジェクトの名前に対する変更を含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
17. 前記Ｉ／Ｏ要求は、前記ファイルシステム内での前記オブジェクトの位置に対する変更を含むことを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
18. コンピュータが、フィルタの名前空間とファイルシステムの名前空間との間で一貫性を維持する方法であって、
    前記ファイルシステムのオブジェクトについてのＩ／Ｏ要求を受け取るステップと、
    前記受け取ったＩ／Ｏ要求に基づいて、前記オブジェクトが、前記フィルタに関連付けられた名前空間内にあるオブジェクトであるかどうかを判定するステップと、
    前記オブジェクトが前記フィルタに関連付けられた名前空間内にあるオブジェクトである場合に、前記Ｉ／Ｏ要求が前記オブジェクトの名前変更動作であるかどうかを判定するステップと、
    前記Ｉ／Ｏ要求が前記オブジェクトの名前変更動作である場合に、前記受け取ったＩ／Ｏ要求に基づいて前記フィルタの名前空間を維持するデータ構造内の前記オブジェクトの名前を変更することによって、前記フィルタに関連付けられた前記名前空間を更新するステップと
    を備えることを特徴とする方法。
19. 前記フィルタが、コールバックコンテキストを割る振るステップと、
    前記フィルタが、動作後コールバックを実行するステップとをさらに備えることを特徴とする請求項１８に記載の方法。
20. 前記名前空間を更新するステップは、
    新しいオブジェクトの新しいノードを前記データ構造に追加するステップと、
    旧ノードに関連付けられたポリシーを前記新しいノードに移動するステップと、
    前記データ構造から前記旧ノードを削除するステップと
    を含むことを特徴とする請求項１８に記載の方法。
21. 複数のフィルタをフィルタマネージャの登録機構に登録するステップと、
    前記複数のフィルタのうちの少なくとも１つのフィルタが、コールバックデータを前記複数のフィルタのうちの少なくとも１つの他にフィルタに渡すステップと
    をさらに含むことを特徴とする請求項１８に記載の方法。

Images