(57)【要約】【課題】  フィルタドライバが管理され、フィルタドライバが関係を登録した入出力要求のコールバックを受け取るモデルを提供する。【解決手段】  フィルタドライバのボリュームごとのインスタンスが、プリコールバック（ファイルシステムへの入出力）およびポストコールバック（ファイルシステムからの入出力）についてフィルタマネージャに登録し、コールバックを受け取るために登録する入出力要求（たとえば、作成、読取、書込）を識別する。フィルタマネージャは、コールバックについてインスタンスを順序付ける。入出力要求が受け取られる時に、フィルタマネージャが、入出力要求をコールバックデータに変換し、関係するフィルタをコールバック順序で呼び出し、これによって、フィルタインスタンスが、入出力データを処理できるようになる。要求がファイルシステムから返される時に、ポストコールバックを望むフィルタが、逆の順序で呼び出される。【選択図】  図４
2004192648.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ環境において、
ファイルシステムに向けられたファイルシステム入出力要求を受け取ることと、
前記入出力要求に対応するデータを最初のフィルタドライバに渡すことを含む、プリコールバック順序に基づいてプリコールバックを用いて前記最初のフィルタドライバを呼び出すことと、
前記プリコールバック順序に基づく最後のフィルタドライバを呼び出すことを含み、前記入出力要求に対応するデータを前記最後のフィルタドライバに渡すことを含む、別のプリコールバックを用いて少なくとも１つの他のフィルタドライバを呼び出すことと、
前記ファイルシステム入出力要求を前記ファイルシステムに渡すことであって、前記ファイルシステム入出力要求は、前記フィルタドライバの少なくとも１つによって処理された前記入出力要求に対応するデータを含む、ことと
を含むことを特徴とする方法。
【請求項２】
前記ファイルシステム入出力要求内のデータを、前記最初のフィルタドライバに渡すためにコールバックデータに変換することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記最後のフィルタドライバから受け取られるコールバックデータを、前記ファイルシステムに渡される前記ファイルシステム入出力要求に再変換することをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記入出力要求に対応するデータを前記最初のフィルタドライバに渡すことは、前記入出力要求内の暗黙の情報に基づいて前記最初のフィルタドライバに明示的コンテキストを渡すことを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記最初のフィルタからフィルタドライバ登録要求を受け取ることをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記プリコールバック順序内の各他のフィルタドライバに関して前記プリコールバック順序内で前記最初のフィルタドライバを順序付けることを含む、前記要求に応答して前記最初のフィルタドライバを登録することをさらに含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記最初のフィルタドライバを登録することは、特定のファイルシステムボリュームに関して前記フィルタドライバのインスタンスを登録することを含むことを特徴とする請求項６に記載の方法。
【請求項８】
特定のファイルシステムボリュームに関して登録される前記フィルタドライバの前記インスタンスは、そのボリュームに関して登録される前記フィルタドライバの別のインスタンスと同一のタイプのフィルタドライバを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記最初のフィルタドライバは、前記最初のファイルシステムが関係するファイル入出力要求の少なくとも１つのタイプの組を示すことを特徴とする請求項１に記載の方法。
【請求項１０】
ファイル入出力要求のタイプのそれぞれについて順序付きリストを構成することをさらに含み、前記順序付きリストは、入出力要求のそのタイプに関係する各フィルタドライバの順序を示すことを特徴とする請求項９に記載の方法。
【請求項１１】
第２ファイルシステム入出力要求を前記ファイルシステムに渡した後に、前記最初のまたは最後のファイルシステムフィルタドライバの少なくとも１つでのポストコールバックオペレーションをコールバックすることをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記コールバックに応答して、前記最初のフィルタドライバからステータス値を受け取ることをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記プリコールバックに応答して、前記最初のフィルタドライバからステータス値を受け取ることをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記ステータス値は、成功およびポストコールバックを用いてコールバックされないことの要求を示し、さらに、前記最初のフィルタドライバをポストコールバックを用いて呼び出さずに前記最初のファイルシステム入出力要求のオリジネータに前記最初のファイルシステム入出力要求に対応するデータを返すことを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ステータス値は、成功およびポストコールバックを用いて呼び出されることの要求を示し、さらに、前記最初のフィルタドライバに前記入出力要求に対応するデータを渡すことを含めて、ポストコールバック順序に基づいてポストコールバックを用いて最初のフィルタドライバを呼び出すことを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記最初のフィルタドライバへの前記ポストコールバックに応答して、終了ステータスを示すステータス値を受け取ることをさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記最初のフィルタドライバへの前記ポストコールバックに応答して、追加処理が要求されることを示すステータス値を受け取ることと、前記追加処理が完了したことを示す前記最初のフィルタドライバからの呼出しを受け取ることとをさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１８】
前記ステータス値は、保留ステータスを示し、前記保留ステータスが完了したことを示す前記最初のフィルタドライバからの呼び出しを受け取ることをさらに含むことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記ステータス値は、同期ステータスを示すことを特徴とする請求項１３に記載の方法。
【請求項２０】
前記ステータス値は、高速入出力が却下されたことを示すことを特徴とする請求項１３に記載の方法。
【請求項２１】
前記プリコールバック順序は、各フィルタドライバの高度に基づき、さらに、前記最初のフィルタドライバによって提供される情報に基づいて前記最初のフィルタドライバの高度を導出することを含むことを特徴とする請求項１に記載の方法。
【請求項２２】
さらに、前記最初のフィルタドライバから登録要求を受け取ることを含み、前記要求は、前記高度がそこから導出される前記最初のフィルタドライバによって提供される前記情報を含むことを特徴とする請求項２１に記載の方法。
【請求項２３】
ポストコールバック順序に基づいて、ポストコールバックを用いて前記最初のフィルタドライバを呼び出すことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項２４】
前記最初のフィルタドライバへの前記プリコールバックに関する前記最初のフィルタドライバのデータを保存することと、前記保存されたデータの少なくとも一部を検索し、前記ポストコールバックに関して前記最初のフィルタドライバに供給することをさらに含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記最初のフィルタドライバのデータを保存することは、データを完了ノードスタックにプッシュすることを含むことを特徴とする請求項２３に記載の方法。
【請求項２６】
前記最後のフィルタドライバがポストコールバックを要求したかどうかを判定することと、そうである場合（要求した場合）に、ａ）前記最後のドライバへの前記プリコールバックに関する前記最後のフィルタドライバのデータを保存することと、ｂ）前記保存されたデータの少なくとも一部を検索し、前記最後のフィルタドライバに提供することを含めて、ポストコールバックを用いて前記最後のフィルタドライバを呼び出すこととをさらに含むことを特徴とする請求項１に記載の方法。
【請求項２７】
前記最後のフィルタドライバのデータを保存することは、前記最後のフィルタが別のフィルタドライバへのポストコールバックに関して保存された他のデータを修正したかどうかを判定することと、そうである場合に、前記最後のフィルタドライバおよび前記別のフィルタドライバの保存されたデータとして前記他のデータを使用することとを含むことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記最初のフィルタドライバにコンテキストを返す要求を受け取ることと、前記要求に応答して前記コンテキストに対応するデータを返すこととをさらに含むことを特徴とする請求項１に記載の方法。
【請求項２９】
コンテキストデータを前記最初のフィルタドライバに返すことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３０】
前記コンテキストデータが、要求に応答して返されることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記コンテキストデータが、通知の一部として返されることを特徴とする請求項２９に記載の方法。
【請求項３２】
前記コンテキストデータは、ストリームハンドルに対応することを特徴とする請求項２９に記載の方法。
【請求項３３】
前記コンテキストデータは、ストリームに対応することを特徴とする請求項２９に記載の方法。
【請求項３４】
前記コンテキストデータは、ファイルに対応することを特徴とする請求項２９に記載の方法。
【請求項３５】
前記コンテキストデータは、ボリュームに対応することを特徴とする請求項２９に記載の方法。
【請求項３６】
前記コンテキストデータは、インスタンスに対応することを特徴とする請求項２９に記載の方法。
【請求項３７】
ツリーを維持することと、前記コンテキストデータについて前記ツリーを検索することとをさらに含むことを特徴とする請求項２９に記載の方法。
【請求項３８】
キーを受け取ることと、前記キーに基づいて前記キーを検索することとをさらに含むことを特徴とする請求項２９に記載の方法。
【請求項３９】
前記キーは、ファイルオブジェクト識別子およびインスタンス識別子を含むことを特徴とする請求項３８に記載の方法。
【請求項４０】
前記キーは、インスタンス識別子を含むことを特徴とする請求項３８に記載の方法。
【請求項４１】
前記ツリーは、ノードを含み、各ノードは、インスタンスに対応することを特徴とする請求項３７に記載の方法。
【請求項４２】
前記ツリーは、ストリームに対応することを特徴とする請求項３７に記載の方法。
【請求項４３】
前記ツリーが、前記ファイルシステムによって維持される他のストリームデータに論理的にアタッチされることを特徴とする請求項４２に記載の方法。
【請求項４４】
前記ファイルシステムに向けられた最初のファイルシステム入出力要求を受け取ることは、レガシフィルタから入出力要求パケットを受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項４５】
前記ファイルシステムに向けられた前記ファイルシステム入出力要求は、エンティティから受け取られる入出力要求パケットを含み、さらに、対応する入出力要求パケットを前記エンティティに返すことを含むことを特徴とする請求項１に記載の方法。
【請求項４６】
前記最初のフィルタドライバから受け取られるコールバックデータを前記エンティティに返される入出力要求パケットに再変換することをさらに含むことを特徴とする請求項４５に記載の方法。
【請求項４７】
前記ファイルシステムに向けられた前記最初のファイルシステム入出力要求を受け取ることは、レガシフィルタから入出力要求パケットを受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項４８】
前記レガシフィルタに入出力要求パケットを返すことをさらに含むことを特徴とする請求項４７に記載の方法。
【請求項４９】
前記最初のフィルタドライバで開始される別の入出力要求を受け取ることと、前記入出力要求に対応するコールバックデータを用いて少なくとも１つの他のフィルタドライバをプリコールすることを含めて、前記ファイルシステムに向けて前記別の入出力要求を送ることとをさらに含むことを特徴とする請求項１に記載の方法。
【請求項５０】
前記別の入出力要求は、ファイルを作成する要求を含み、前記要求を開始したものとして前記最初のフィルタドライバを識別するヒントを用いてファイルを作成することをさらに含むことを特徴とする請求項４９に記載の方法。
【請求項５１】
請求項１に記載の方法を実行するコンピュータ実行可能命令を有するコンピュータ可読媒体。
【請求項５２】
オペレーティングシステムおよびファイルシステムを有するコンピュータ環境であって、オペレーティングシステムは、ファイルシステム関連関数の呼出しを受け取り、前記ファイルシステムに向けて対応する入出力要求データを提供するコンポーネントを含む、コンピュータ環境において、
複数のフィルタドライバと、
フィルタマネージャであって、
ａ）前記フィルタドライバのそれぞれを登録し、
ｂ）各プリコールバック順序が、１つまたは複数の前記フィルタドライバの組に対応する、少なくとも１つのプリコールバック順序で前記フィルタドライバを配置し、
ｃ）前記要求データを受け取り、
ｄ）前記要求に基づいて、呼び出される各フィルタドライバにコールバックデータを提供することを含めて、選択されたプリコールバック順序に基づいて前記フィルタドライバの少なくとも１つを呼び出し、
ｅ）呼び出された各フィルタドライバからステータスを受け取り、
ｆ）前記コールバックデータに対応するデータを含む入出力要求を前記ファイルシステムに向けて渡す
フィルタマネージャと
を含むことを特徴とするシステム。
【請求項５３】
前記入出力要求データは、入出力要求パケット内の情報を含むことを特徴とする請求項５２に記載のシステム。
【請求項５４】
前記フィルタマネージャは、前記入出力要求パケットをコールバックデータに変換することを特徴とする請求項５３に記載のシステム。
【請求項５５】
前記フィルタマネージャは、前記入出力要求内の暗黙の情報に基づいて最初のフィルタドライバに明示的コンテキストを渡すことによって、前記入出力要求パケットをコールバックデータに変換することを特徴とする請求項５４に記載のシステム。
【請求項５６】
前記選択されたプリコールバック順序は、最初のフィルタおよび最後のフィルタを含み、前記最初のフィルタは、前記フィルタマネージャがプリコールバックを用いて前記フィルタを呼び出す順序に関して前記最後のフィルタの前に順序付けられることを特徴とする請求項５２に記載のシステム。
【請求項５７】
前記選択されたプリコールバック順序は、前記フィルタマネージャがプリコールバックを用いて前記フィルタを呼び出す順序に関して最初のフィルタの後、前記最後のフィルタの前に順序付けられる中間フィルタを含むことを特徴とする請求項５６に記載のシステム。
【請求項５８】
前記各フィルタは、特定のファイルシステムボリュームに関して登録されるフィルタドライバのインスタンスを含むことを特徴とする請求項５２に記載のシステム。
【請求項５９】
前記特定のファイルシステムボリュームに関して登録されたフィルタドライバの少なくとも２つのインスタンスは、同一タイプのフィルタドライバを含むことを特徴とする請求項５８に記載のシステム。
【請求項６０】
前記各フィルタドライバは、そのフィルタドライバがプリコールバックの受取に関係するファイル入出力要求の少なくとも１つのタイプを示すことを特徴とする請求項５２に記載のシステム。
【請求項６１】
各プリコールバック順序は、ファイル入出力要求のタイプに対応し、前記フィルタマネージャは、各フィルタドライバがプリコールバックの受取への関係を示した１つまたは複数のファイル入出力要求タイプに基づいて、各プリコールバック順序で前記フィルタドライバを配置することを特徴とする請求項６０に記載のシステム。
【請求項６２】
その中で複数のフィルタドライバが識別されるプリコールバック順序のそれぞれについて、前記フィルタマネージャは、各フィルタドライバに関連する高度に基づいてプリコールバック順序内で前記フィルタドライバを順序付けることを特徴とする請求項６１に記載のシステム。
【請求項６３】
前記フィルタマネージャは、各フィルタドライバに関連する高度を前記フィルタドライバによって供給される情報から導出することを特徴とする請求項６２に記載のシステム。
【請求項６４】
前記フィルタドライバは、ポストコールバックオペレーションで少なくとも１つのフィルタドライバをコールバックすることを特徴とする請求項５２に記載のシステム。
【請求項６５】
前記最初のフィルタドライバへの前記ポストコールバックに応答して、終了ステータスを示すステータス値を受け取ることを特徴とする請求項６４に記載のシステム。
【請求項６６】
前記最初のフィルタドライバへの前記ポストコールバックに応答して、追加処理が要求されることを示すステータス値を受け取ることをさらに含むことを特徴とする請求項６４に記載のシステム。
【請求項６７】
呼び出されたフィルタドライバから受け取る前記ステータス値は、成功およびポストコールバックを用いてコールバックされないことの要求を示すことを特徴とする請求項５２に記載のシステム。
【請求項６８】
呼び出されたフィルタドライバから受け取る前記ステータス値は、成功およびポストコールバックを用いて呼び出されることの要求を示すことを特徴とする請求項５２に記載のシステム。
【請求項６９】
呼び出されたフィルタドライバから受け取る前記ステータス値は、保留ステータスを示し、前記最初のフィルタドライバは、他のフィルタドライバを呼び出す前に、前記保留ステータスが完了したことを示す、前記呼び出されたフィルタドライバからの情報を待つことを特徴とする請求項５２に記載のシステム。
【請求項７０】
呼び出されたフィルタドライバから受け取る前記ステータス値は、同期ステータスを示すことを特徴とする請求項５２に記載のシステム。
【請求項７１】
呼び出されたフィルタドライバから受け取る前記ステータス値は、高速入出力が却下されたことを示すことを特徴とする請求項５２に記載のシステム。
【請求項７２】
前記フィルタマネージャは、プリコールバックを用いて呼び出された前記フィルタドライバの少なくとも１つのパラメータ情報を保存し、ポストコールバックオペレーション中に、前記保存されたパラメータ情報の少なくとも一部を検索し、そのフィルタドライバに提供することを特徴とする請求項５２に記載のシステム。
【請求項７３】
前記フィルタマネージャは、データを完了ノードスタックにプッシュすることによって、前記パラメータ情報を保存することを特徴とする請求項７２に記載のシステム。
【請求項７４】
前記フィルタマネージャは、フィルタドライバにコンテキストを返す要求を受け取り、前記フィルタマネージャは、前記要求に応答して、前記コンテキストに対応するデータを返すことを特徴とする請求項５２に記載のシステム。
【請求項７５】
コンテキスト構造体をさらに含み、前記コンテキスト構造体が、フィルタドライバに論理的に返されることを特徴とする請求項５２に記載のシステム。
【請求項７６】
前記コンテキスト構造体が、前記フィルタドライバから前記フィルタマネージャに対して行われる要求に応答して返されることを特徴とする請求項７５に記載のシステム。
【請求項７７】
前記コンテキスト構造体は、ストリームハンドルに対応することを特徴とする請求項７５に記載のシステム。
【請求項７８】
前記コンテキスト構造体は、ストリームに対応することを特徴とする請求項７５に記載のシステム。
【請求項７９】
前記コンテキスト構造体は、ファイルに対応することを特徴とする請求項７５に記載のシステム。
【請求項８０】
前記コンテキスト構造体は、ボリュームに対応することを特徴とする請求項７５に記載のシステム。
【請求項８１】
前記コンテキスト構造体は、インスタンスに対応することを特徴とする請求項７５に記載のシステム。
【請求項８２】
前記フィルタマネージャは、ストリームに関連するノードのツリーを維持し、各ノードは、インスタンスを表し、前記フィルタドライバは、前記ツリー内の情報に基づいて前記コンテキスト構造体の所在を突き止めるキーとして前記フィルタマネージャにファイルオブジェクト識別子およびインスタンス識別子を提供することを特徴とする請求項７５に記載のシステム。
【請求項８３】
前記フィルタマネージャは、ストリームに関連するノードのツリーを維持し、各ノードは、インスタンスを表し、前記フィルタドライバは、前記ツリー内の情報に基づいて前記コンテキスト構造体の所在を突き止めるキーとして前記フィルタマネージャにインスタンス識別子を提供することを特徴とする請求項７５に記載のシステム。
【請求項８４】
前記フィルタマネージャは、ストリームに関連するノードのツリーを維持し、前記ツリーが、そのストリームの前記ファイルシステムによって維持される他のストリームデータに論理的にアタッチされることを特徴とする請求項７５に記載のシステム。
【請求項８５】
前記オペレーティングシステムコンポーネントから前記ファイルシステムに向けられるパケットとして前記入出力要求データを受け取り、前記入出力要求データをパケットとして前記フィルタマネージャに提供するレガシフィルタをさらに含むことを特徴とする請求項５２に記載のシステム。
【請求項８６】
前記フィルタマネージャは、前記入出力要求を前記ファイルシステムに向けて渡した後に、入出力要求パケットを前記レガシフィルタに返すことを特徴とする請求項８５に記載のシステム。
【請求項８７】
前記フィルタマネージャは、フィルタドライバで開始された別の入出力要求を受け取り、前記フィルタドライバで開始された前記別の入出力要求に対応するコールバックデータを用いる少なくとも１つの他のフィルタドライバのプリコールの後に、前記フィルタドライバで開始された前記別の入出力要求を前記ファイルシステムに向けて送ることを特徴とする請求項８５に記載のシステム。
【請求項８８】
前記別の入出力要求は、ファイルを作成する要求を含み、前記フィルタドライバは、前記最初のフィルタドライバを識別するヒントを用いる前記ファイルの作成を要求することを特徴とする請求項８７に記載のシステム。
【請求項８９】
その上にデータ構造体を保管されたコンピュータ可読媒体であって、
ファイルシステム入出力要求のあるタイプに関連するものとして前記構造体を識別する情報の第１組と、
ファイルシステム入出力要求の前記タイプに関連する複数のフィルタドライバを識別する情報の第２組と、
前記フィルタドライバのお互いに関する順序付けを識別する情報の第３組と
を含み、情報の前記第１組に対応するファイルシステム入出力要求に応答して、エンティティが、情報の前記第３組によって決定される順序で、プリコールバックを用いて前記第２組の前記フィルタドライバのそれぞれを呼び出す
ことを特徴とするコンピュータ可読媒体。
【請求項９０】
請求項８９に記載のコンピュータ可読媒体のデータ構造体であって、情報の前記第１組は、ファイルの作成を対象とするファイルシステム入出力要求に対応することを特徴とするデータ構造体。
【請求項９１】
請求項８９に記載のコンピュータ可読媒体のデータ構造体であって、情報の前記第１組は、ファイルのオープンを対象とするファイルシステム入出力要求に対応することを特徴とするデータ構造体。
【請求項９２】
請求項８９に記載のコンピュータ可読媒体のデータ構造体であって、情報の前記第１組は、ファイルからの読取を対象とするファイルシステム入出力要求に対応することを特徴とするデータ構造体。
【請求項９３】
請求項８９に記載のコンピュータ可読媒体のデータ構造体であって、情報の前記第１組は、ファイルへの書込を対象とするファイルシステム入出力要求に対応することを特徴とするデータ構造体。
【請求項９４】
請求項８９に記載のコンピュータ可読媒体のデータ構造体であって、情報の前記第１組は、ファイルのクローズを対象とするファイルシステム入出力要求に対応することを特徴とするデータ構造体。
【請求項９５】
請求項８９に記載のコンピュータ可読媒体のデータ構造体であって、情報の前記第２組は、呼び出すべきフィルタドライバのリストを含み、前記フィルタドライバの順序付けを識別する情報の前記第３組が、前記リスト内の前記フィルタドライバの前記順序に組み込まれることを特徴とするデータ構造体。
【請求項９６】
コンピュータ環境において、
複数のフィルタドライバをコールバック順序で登録することであって、前記複数は、上位フィルタドライバの下、下位フィルタドライバの上の中間フィルタドライバを含む、登録することと、
前記中間フィルタドライバで開始されるファイルシステムに向けられる入出力要求を受け取ることと、
前記入出力要求が前記中間フィルタドライバによって開始されたことを示す情報を維持することと、
前記入出力要求を前記ファイルシステムに向かって送ることと、
前記入出力要求に対応するステータスデータを前記ファイルシステムから受け取ることと、
前記入出力要求を開始した前記中間フィルタドライバに前記ステータスデータを返すことと、
前記ステータスデータを前記上位フィルタドライバに渡さないように、前記入出力要求が前記中間フィルタドライバによって開始されたことを示す前記情報にアクセスすることと
を含むことを特徴とする方法
【請求項９７】
前記入出力要求に対応するコールバックデータを用いて前記下位フィルタドライバをプリコールすることをさらに含むことを特徴とする請求項９６に記載の方法
【請求項９８】
前記ステータスデータに対応するコールバックデータを用いて前記下位フィルタドライバをポストコールすることをさらに含むことを特徴とする請求項９７に記載の方法
【請求項９９】
前記入出力要求は、ファイルを作成する要求を含み、前記情報を維持することは、前記要求を開始したものとして前記中間フィルタドライバを識別するヒントを用いる前記ファイルの作成を要求することを含むことを特徴とする請求項９６に記載の方法
【請求項１００】
前記作成されるファイルに対応する前記中間フィルタドライバで開始される書込要求を受け取ることと、前記書込要求を前記ファイルシステムに向けて送ることと、前記ファイルシステムから前記書込要求に対応するステータスデータの別の組を受け取ることと、ステータスデータの前記別の組を前記中間フィルタドライバに返すことと、前記別のステータスデータを前記上位フィルタドライバに渡さないように、ステータスデータの前記他の組が前記ヒントを用いて作成された前記ファイルに対応することを判定するために前記情報にアクセスすることをさらに含むことを特徴とする請求項９９に記載の方法
【請求項１０１】
前記作成されるファイルに対応する前記中間フィルタドライバで開始される読取要求を受け取ることと、前記読取要求を前記ファイルシステムに向けて送ることと、前記読取要求に対応するステータスデータの別の組を前記ファイルシステムから受け取ることと、ステータスデータの前記別の組を前記中間フィルタドライバに返すことと、ステータスデータの前記別の組を前記上位フィルタドライバに渡さないように、ステータスデータの前記他の組が前記ヒントを用いて作成された前記ファイルに対応することを判定するために前記情報にアクセスすることをさらに含むことを特徴とする請求項９９に記載の方法
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にはコンピュータシステムに関し、具体的には、ファイルシステムおよびファイルシステムフィルタに関する。
【背景技術】
【０００２】
Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳ（Ｗｉｎｄｏｗｓ（登録商標）ＮＴファイルシステム）、ＦＡＴ（File Allocation Table）、ＣＤＦＳ(Compact Disc File System)、ＳＭＢ(Server Message Block)リダイレクタファイルシステム、またはＷｅｂＤａｖファイルシステムなどの基礎になるファイルシステムを伴う、Ｍｉｃｒｏｓｏｆｔ(マイクロソフト)  社のＷｉｎｄｏｗｓ（登録商標）ＸＰオペレーティングシステムなどの現代のオペレーティングシステムでは、１つまたは複数のファイルシステムフィルタドライバが、ユーザ入出力要求を受け取る入出力マネージャとファイルシステムドライバの間に挿入される場合がある。一般に、フィルタドライバ（‘フィルタ’）は、アンチウィルスソフトウェア、ファイルシステム割り当てプロバイダ、ファイルレプリケータ、暗号化／圧縮化製品を介してファイルシステム入出力（要求およびデータ）を渡すことなどのタスクを含む、ユーザが望むさまざまなファイル関連計算タスクを実行することによって、基礎となるファイルシステムを機能強化するカーネルモードドライバである。たとえば、アンチウィルス製品は、ある種のファイルタイプ（たとえば、  ．ｅｘｅ（ファイル名拡張子の一つ）、  ．ｄｏｃ（ファイル拡張子の一つ）および類似物など）との間の入出力を監視して、ウィルスシグネチャ（ウィルスの痕跡）を探し、その間にファイルレプリケーション製品は、ファイルシステムレベルのミラーリングを実行する。他のタイプのファイルシステムフィルタドライバは、システム回復（変更が行われようとしている時にシステムファイルをバックアップし、その結果、ユーザが元の状態に戻れるようにする）、ディスク割り当て実施、オープンファイルのバックアップ、削除されたファイルのアンデリート（復活）、ファイルの暗号化などを対象とする。したがって、ファイルシステムフィルタドライバをインストールすることによって、コンピュータユーザは、実際のオペレーティングシステムまたはファイルシステムドライバコードを変更する必要なしにコンポーネント（構成要素）のアップグレード（性能向上）、置換、挿入、除去を可能にする形で、ユーザが望み、必要とするファイルシステム機能を選択することができる。
【０００３】
現代のＷｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステム（たとえば、Ｗｉｎｄｏｗｓ（登録商標）ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）２０００、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ、Ｗｉｎｄｏｗｓ（登録商標）．ＮＥＴ  Ｓｅｒｖｅｒ  ２００３）の既存のファイルシステムフィルタモデルによって、パケットベースの手法である固有の入出力モデルが活用される。このために、ファイルシステムフィルタが、スタック内の通常のドライバとしてロードされ、基礎となるファイルシステムのボリュームデバイスオブジェクトにアタッチされる。ユーザ入出力要求は、入出力マネージャによって入出力要求パケット（ＩＲＰ）に変換され、このＩＲＰが、ドライバスタックに送られ、一番上のドライバによって処理され、ドライバは、ＩＲＰを完了し、ファイルシステムに向かって別のドライバへの下への呼出しで渡し、別のドライバは、次に下位のドライバを呼び出し、以下同様である。一般に、各ドライバは、ＩＲＰに対して実行するようにコーディングされたすべてのものを処理し、ＩＲＰを次に下位のドライバ（または、それより下位がない場合にはファイルシステム）に明示的に渡すか、ＩＲＰを完了（または失敗）し、スタック内で次に上位のドライバ（または、それより上位がない場合には入出力マネージャ）に送り返す。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この既存のフィルタドライバモデルによって、高いフレキシビリティ（柔軟性、順応性）を含む複数の利益がもたらされるが、それに特有の幾多の問題もある。まず、ファイルシステムフィルタへの書込は、主に基礎となる複雑なファイルシステムの結果として、単純でない作業である。フィルタは、従来デバッグおよび保守が困難な、非常に複雑なソフトウェアである。複雑性の多くは、フィルタによるパケットの扱い、たとえば、ＩＲＰを理解し、操作する必要から生じる。その結果、信頼性が悪くなり、少なくとも１つの調査から、フィルタが、システムクラッシュ（機能停止）にかなりの比率で責任があることが示された。
【０００５】
もう１つの問題が、効率である。というのは、ファイルシステムフィルタは、従来、関係しないものであっても、通常はファイルシステムに向かうすべてのオペレーションを受け取り、処理するからである。たとえば、アンチウィルス製品は、６０％ほどシステムを低速にする可能性があるが、アンチウィルスフィルタによって受け取られる入出力要求には、フィルタが何か（すなわち、ウィルスについて対応するデータを検査する）を行う入出力要求ではないものがある。冗長性も、問題であり、これは、非効率性および計算コストにつながる。というのは、多数のフィルタが、異なる形で同一のことを行い、不必要なコードにつながるからである。
【０００６】
ドライバの間のインターオペラビリティ（相互運用）も重要な問題である。というのは、たとえば、あるドライバが、他のドライバが予想せず、正しく扱えない形で入出力を修正する可能性があるからである。フィルタが、ファイルシステムへのアタッチ（取り付け）順序付けの非常に粗い粒度の制御だけを有することに部分的に起因して、インターオペラビリティの問題は、既存モデルの最大の短所の１つである。
【０００７】
他の問題には、複数のフィルタがインストールされている時に、フィルタによって発行される再帰的再入可能入出力に起因してスタックオーバーフロー（はみ出し）が一般的なので、スタックスペースのオーバーフローが含まれる。デッドロックも、やはり主に再入可能入出力に起因して、既存モデルで一般的である。他の問題には、スタック内のフィルタを動的に（すなわち、システムリブートなしで）ロードし、アンロードする能力がないことが含まれる。
【０００８】
要約すると、既存のフィルタドライバモデルは、幾多の重大な短所を有する。必要とするものは、ファイルシステム入出力要求および関連データを処理するファイルシステムフィルタの改善されたモデルおよびアーキテクチャである。
【課題を解決するための手段】
【０００９】
手短に言うと、本発明は、フィルタドライバが、フィルタマネージャによって管理されて、フィルタドライバが関係を登録した入出力要求についてコールバックを受け取るモデル／アーキテクチャを提供する。このモデルでは、ＩＲＰ、高速入出力パス、Ｆｓフィルタコールバックなどが、フィルタマネージャによってコールバックに変換され、このコールバックによって、明示的で明確に定義されたフォーマットでコールバックデータがフィルタに供給されるようにする管理されるコールバックモデルを提供することによって、従来の複雑な入出力渡しが除去される。以下で説明するように、フィルタによって、コールバックデータが望み通りに操作され、コールバックに応答してステータスが返される。１つの結果として、フィルタは、もはやＩＲＰを扱う必要がない。
【００１０】
一般に、フィルタマネージャは、ＩＲＰ、高速入出力、ＦＳフィルタコールバック、または類似物のどれであれ、入出力を、「コールバックデータ」と称する均一な構造体に変換する。このために、フィルタマネージャを、レガシ（legacy）フィルタドライバであるかのようにレガシフィルタドライバスタックに配置することができ、その結果、フィルタマネージャが、ＩＲＰを受け取り、処理することができるようになる。フィルタマネージャは、適切に登録されたフィルタドライバのリストをたどって、入出力に関して登録されたディスパッチ(dispatch)を呼び出す。
【００１１】
フィルタドライバには、インスタンス化される時にフィルタマネージャ内の登録機構に登録されるオブジェクト（または類似するコンポーネント）を含めることができる。フィルタドライバは、それが関係する入出力要求のタイプ（たとえば、作成、読取、書込、クローズ（閉じ）など）をフィルタマネージャに通知することによって、処理に関係する可能性があるファイルシステム要求についてのみ登録する。その結果、このモデルは、フィルタドライバが関係しない入出力要求を見ず、したがってそれについて登録されないので、スタック式フィルタモデルより効率的である。  
【００１２】
一実施形態では、フィルタドライバが、ボリュームごとの方式でフィルタドライバインスタンスとしてボリュームに別々にアタッチされ、フィルタドライバは、複数のインスタンスを同一ボリュームにアタッチすることができる。各フィルタドライバインスタンスは、コールバック順序のどこにそのドライバが位置するかを示す‘高度（ａｌｔｉｔｕｄｅ）’に関連付けられる。高度は、事前定義とすることができ、あるいは、ドライバがコールバックデータに対して実行する処理のタイプを示す、ドライバによって与えられるフラグから導出することができる。
【００１３】
どのフィルタドライバが、どのタイプのコールバックについて登録されているかを効率的に追跡し、これによって、適切なドライバを正しい順序で効率的にコールバックするために、フィルタマネージャは、ボリュームごとに順序付きリストを維持し、このリストのそれぞれは、フィルタがプリコールバックおよび／またはポストコールバックの受取への関係を登録したオペレーションのタイプによってインデクシング（索引付け）される。フィルタマネージャは、このリストを使用して、適切な順序でフィルタをコールバックし、各フィルタは、ステータスを返す。成功を仮定すると、最後のプリコールバックに続いて、フィルタマネージャが、コールバックデータをＩＲＰに再変換し、そのＩＰＲをファイルシステムに送る。
【００１４】
ポストコールバックは、本質的に、逆の順序で動作するが、フィルタが、ポストコールバック中にスキップ（省略、飛び越し）されることを望むことを示すことができる。入出力完了は、フィルタマネージャによって、プリコールバックでフィルタインスタンスによって見られたパラメータがポストコールバックでも同一であることが保証される形で処理される。このために、フィルタマネージャは、完了ノードスタックを維持し、これにアクセスして、各ポストコールバックで正しいパラメータを返す。
【００１５】
フィルタマネージャによって、フィルタが共通して必要とする機能を提供する豊富なＡＰＩセットも提供される。たとえば、ある種のフィルタは、それ自体で入出力を実行することを必要とし、そのようなオペレーションを容易にするさまざまな機能が、提供される。さまざまな機能によって、インスタンス、ボリューム、ファイル、ストリームハンドル、またはストリームに関する効率的なコンテキストサポートも提供され、適切なオブジェクトに関連する各フィルタのコンテキストデータが、記憶される。本発明は、エンティティに関する通知をセットアップし、フィルタごとのコンテキストのそのエンティティとの関連付けを単純にするコールバックの組を介する通知サポートも提供する。コンテキストは、いつでもセットし、かつ／またはリセットすることができる。さらなる他の機能によって、カーネルモードフィルタドライバとユーザモードの対応するサービスおよびプログラムの間の通信が可能になり、他の機能によって、本願発明の関連出願である２００２年８月２８日付け出願の米国特許出願第１０／１８７，１１９号に記載されたネーミングサポートが提供される。
【００１６】
他の長所は、図面と共に検討される時に以下の詳細な説明から明白になる。
【発明を実施するための最良の形態】
【００１７】
例示的なオペレーティング環境
図１に、本発明を実施することができる好適なコンピュータシステム環境１００の例を示す。コンピュータシステム環境１００は、好適なコンピュータ環境の１つの例にすぎず、本発明の使用または機能性の範囲に関する限定を示唆することは意図されていない。コンピュータ環境１００を、例示的なオペレーティング環境１００に示されたコンポーネントのいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。
【００１８】
本発明は、多数の他の汎用または特殊目的のコンピュータシステム環境またはコンピュータシステム構成と共に使用できる。本発明と共に使用するのに適する可能性がある周知のコンピュータシステム、環境、および／または構成の例に、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド機、ラップトップ機、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル一般電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピュータ環境、および類似物が含まれるが、これに限定はされない。
【００１９】
本発明を、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などが含まれる。本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピュータ環境でも実践することができる。分散コンピュータ環境では、プログラムモジュールを、メモリストレージデバイス（記憶装置）を含むローカルおよびリモートの両方のコンピュータストレージメディアに配置することができる。
【００２０】
図１に関して、本発明を実施する例示的システムに、コンピュータ１１０の形での汎用計算機が含まれる。コンピュータ１１０のコンポーネント（構成要素）に、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含むさまざまなシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１を含めることができるが、これに限定されない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含むさまざまなタイプのバス構造のいずれかとすることができる。限定ではなく事例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。
【００２１】
コンピュータ１１０には、通常は、さまざまなコンピュータ可読媒体が含まれる。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできるすべての使用可能なメディアとすることができ、これには、揮発性メディアおよび不揮発性メディアと、取外し可能メディアおよび取外し不能メディアの両方が含まれる。限定ではなく例として、コンピュータ可読媒体に、コンピュータストレージメディア（コンピュータ記憶媒体）および通信メディア（通信媒体）を含めることができる。コンピュータストレージメディアには、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータなどの情報を保管するすべての方法または技術で実施される、揮発性および不揮発性と、取外し可能および取外し不能の両方のメディアが含まれる。コンピュータストレージメディアの例には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を保管するのに使用でき、コンピュータ１１０によってアクセスできる任意の他のメディアが含まれるが、これに限定はされない。通信メディアによって、通常は、搬送波または他のトランスポートメカニズム（機構）などの変調されたデータ信号でコンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータが実施され、通信メディアには、任意の情報配布メディアが含まれる。用語「変調されたデータ信号（modulated data signal）」は、信号内で情報をエンコード(符号化)する形で１つまたは複数の特性を設定または変更された信号を意味する。限定ではなく例として、通信メディアに、有線ネットワークまたは直接配線接続などの有線メディアと、音響（acoustic）、ＲＦ、赤外線、および他の無線メディアなどの無線メディアが含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれる。
【００２２】
システムメモリ１３０には、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性のメモリの形のコンピュータストレージメディア(コンピュータ記憶媒体)が含まれる。起動中などにコンピュータ１１０内の要素の間での情報転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ１３１に保管される。ＲＡＭ１３２には、通常は、処理ユニット１２０から即座にアクセス可能および／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールが保管される。限定ではなく例として、図１に、オペレーティングシステム１３４、ファイルシステム１３５、アプリケーションプログラム１３６、他のプログラムモジュール１３７、およびプログラムデータ１３８を示す。
【００２３】
コンピュータ１１０に、他の取外し可能／取外し不能の、揮発性／不揮発性コンピュータストレージメディアも含めることができる。例としてのみ、図１に、取外し不能不揮発性磁気メディアから読み取り、これに書き込むハードディスクドライブ１４１、取外し可能不揮発性磁気ディスク１５２から読み取り、これに書き込む磁気ディスクドライブ１５１、ＣＤ  ＲＯＭまたは他の光学メディアなどの取外し可能不揮発性光ディスク１５６から読み取り、これに書き込む光ディスクドライブ１５５を示す。例示的オペレーティング環境で使用することができる他の取外し可能／取外し不能の、揮発性／不揮発性コンピュータストレージメディアに、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステート（固体）ＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定はされない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの取外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常は、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００２４】
図１に関して上で説明したドライブおよびそれに関連するコンピュータストレージメディアによって、コンピュータ１１０のコンピュータ可読命令、データ構造体、プログラムモジュール、および他のデータのストレージ（格納、記憶）が与えられる。図１では、たとえば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３６、他のプログラムモジュール１３７、およびプログラムデータ１３８と同一または異なる、のいずれかとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくともこれらが異なるコピー（copies:写し）であることを示すために、本明細書では異なる番号を与えられている。ユーザは、タブレット（電子ディジタイザ）１６４、マイクロホン１６３、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナ、または類似物を含めることができる。これらおよび他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１を、タッチスクリーンパネルまたは類似物と一体化することもできる。タブレット型パーソナルコンピュータの場合のように、モニタおよび／またはタッチスクリーンパネルを、計算機１１０が組み込まれる筐体に物理的に結合できることに留意されたい。さらに、計算機１１０などのコンピュータに、出力周辺インターフェース１９４または類似物を介して接続することができる、スピーカ１９５およびプリンタ１９６などの他の周辺出力デバイスも含めることができる。
【００２５】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア（peer）デバイス、または他の一般的なネットワークノードとすることができ、リモートコンピュータ１８０には、通常、コンピュータ１１０に関して上で説明した要素の多くまたはすべてが含まれるが、図１には、メモリストレージデバイス１８１だけが示されている。図１に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング(連絡網)環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。たとえば、本発明では、コンピュータシステム１１０に、データがそこから移植されるソース計算機を含めることができ、リモートコンピュータ１８０に、宛先計算機を含めることができる。しかし、ソース計算機および宛先計算機が、ネットワークまたは他の手段によって接続される必要はなく、その代わりに、データを、ソースプラットフォームによって書込可能であり、宛先プラットフォームによって読取可能であるメディアを介して移植することができることに留意されたい。
【００２６】
ＬＡＮネットワーキング環境で使用される時に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される時に、コンピュータ１１０に、通常は、インターネットなどのＷＡＮ１７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して図示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに保管することができる。限定ではなく例として、図１に、メモリデバイス１８１に常駐するリモートアプリケーションプログラム１８５を示す。図示のネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段が使用可能であることは、十分に理解できるであろう。
【００２７】
管理されるファイルシステムフィルタモデルおよびアーキテクチャ
本発明は、全般的に、さまざまなファイルシステム関連製品（プロダクト）の間のインターオペラビリティ（相互運用）を促進することによるものを含む、フィルタによってファイルシステム入出力処理を改善することを意図されたファイルシステムフィルタモデルおよびアーキテクチャを対象とする。このモデルが、全般的に、ローカルまたはリモートのファイルシステムとすることができるベースファイルシステムと入出力マネージャの間で動作するフィルタドライバに関して説明され、ファイルシステムとストレージドライバ（ＦｔＤｉｓｋまたはＤＭＩＯなど）の間で動作するフィルタドライバを含む他のドライバに関しては説明されないことに留意されたい。
【００２８】
本明細書で使用される“レガシ（legacy）”フィルタドライバは、以下で説明するように登録されたフィルタドライバへのコールバックを使用する新しいモデルによるのではなく、従来の形で入出力要求パケット（ＩＲＰ）を処理するフィルタドライバである。レガシフィルタドライバが、時間と共に徐々に取り除かれることが期待されるので、新しい登録およびコールバックのモデルに準拠するフィルタドライバを、本明細書では単に“フィルタドライバ”と称する。
【００２９】
新しいフィルタモデルの主な態様の１つが、レガシフィルタからレガシフィルタへのスタックモデルを介する従来の複雑な入出力渡しを除去し、そのモデルを管理されるコールバックモデルに置換することを対象とし、管理されるコールバックモデルでは、ＩＲＰ、高速入出力パス、メモリマネージャコールバックなどが、フィルタマネージャによってコールバックに変換され、これによって、定義されたフォーマットのコールバックデータが、フィルタに供給される。フィルタは、他のフィルタを呼び出さず、他のフィルタに直接に制御を渡すのでもなく、以下で説明するように、望みに応じてコールバックデータを操作し、コールバックに応答してステータスを返す。フィルタは、もはやＩＲＰおよび類似物を扱う必要がないので、入出力ハンドリングの複雑さの多くが、フィルタから除去され、単一のフィルタマネージャに組み込まれ、さまざまなフィルタによって引き起こされる問題の多くが除去される。たとえば、ＩＲＰには、従来はレガシフィルタドライバによる扱いが困難であった暗黙（implicit）の複雑な情報が含まれることがしばしばであるが、本発明は、フィルタマネージャに暗黙の情報を処理させ、明示的なコンテキストだけをフィルタに渡すことによって、この問題を除去する。コールバックモデルは、さらに、チェーンされたＩＲＰディスパッチに起因して生じるスタックオーバーフロー問題およびロック問題を解決するという利点を有する。
【００３０】
図２は、新しいモデルの実施形態２００の例を表す。図２に示された実施形態の長所の１つが、新しいモデルを実施するために、既存のアプリケーション、オペレーティングシステムコンポーネント、およびファイルシステムを、どのような形でも修正する必要がないことである。たとえば、Ｗｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステムでは、アプリケーション２０２が、ＡＰＩレイヤ（層）２０４を介して入出力マネージャ２０６に、ファイルシステム要求（たとえば、関数／メソッド呼出しを介して）を行い続ける。既知の通り、入出力マネージャ２０６は、ＩＲＰまたは他のタイプの入出力を生成し、その入出力を、（レガシ）フィルタドライバスタック２０８の最上部に送る。以下で説明するように、スタック２０８のコンポーネントの１つが、フィルタマネージャ２１２である。
【００３１】
一般に、フィルタマネージャ２１２は、ＩＲＰ、高速入出力、ＦＳフィルタコールバック、または類似物のどれであれ、入出力を、コールバックデータと称する均一な構造体に変換する。好適なコールバックデータ構造体を、以下で説明する。フィルタマネージャ２１２は、登録されたフィルタドライバ（たとえば、５つのそのようなフィルタドライバ２８２Ａから２８２Ｅが、図２に示されているが、任意の数のそのようなドライバが存在することができる）のリストをたどり、フィルタドライバごとに、入出力について登録されたディスパッチを呼び出すことができる。重要なことに、本発明のモデルでは、フィルタが、ＩＲＰを受け取り、かつ／または処理するのではなく、その代わりに、本質的に、入出力要求に関して行うことをフィルタマネージャ２１２に指示する。
【００３２】
図２からわかるように、レガシフィルタドライバ２１０は、この実施形態では、スタック２０８の最上部に配置することによるなど、さらにサポートすることができる。しかし、他のスタックコンポーネントに関する他の順序に配置することも実行可能であることに留意されたい。たとえば、レガシフィルタドライバは、コールバックではなくてＩＲＰを処理するように配置されるので、特殊な管理コードによってそのようなレガシフィルタを囲んで、コールバックデータからＩＲＰを生成して、そのレガシフィルタに渡し、そのレガシフィルタから（おそらくは修正された）ＩＲＰを受け取り、ステータス応答に変換することができる。この形で、レガシフィルタをコールバックモデル内に挿入し、分離することができる。どの場合でも、レガシフィルタを、新しいモデル内で使用することができる。
【００３３】
図２に示された実施形態を要約すると、ファイルシステムフィルタマネージャ２１２が、新しいモデルで使用され、レガシフィルタドライバであるかのようにフィルタドライバスタック２０８に配置され、その結果、ＩＲＰを受け取り、処理することができるようになる。これによって、フィルタマネージャが既存の入出力システム内で単純に動作できるようになるが、更新された入出力マネージャによって、ＩＲＰデータ構造体以外の入出力データがフィルタマネージャに渡される、同等のモデル（たとえば上位レガシフィルタなし）を設けることができることを諒解されたい。たとえば、入出力マネージャがＩＲＰを生成する時に、フィルタドライバは、ＩＲＰからコールバックデータ構造体を生成し、したがって、入出力マネージャにコールバックデータ構造体を直接に生成させる方が効率的になる可能性がある。既存システムで、読取／書込／デバイス入出力制御などの一般的な入出力タスクに関して、より高速の実行のためにパケットベースではなくコールバックベースであるＩＲＰ以外のものが、高速入出力、メモリマネージャコールバックなどのために既に提供されていることに留意されたい。さらに、既存システムで、高速入出力が、まだスタックを介して渡され（すなわち、チェーンされ）、したがって、本発明のコールバックベースのモデルに似ないことに留意されたい。説明を単純にするために、本明細書の説明では、他に注記された場合を除いて、主にＩＲＰの例を使用する。
【００３４】
一実施形態では、フィルタドライバに、通常はドライバ初期化手順中にインスタンス化される時にフィルタマネージャ２１２の登録機構に登録されるオブジェクトまたは類似物が含まれる。効率のために、フィルタドライバは、通常は、処理において関係する可能性があるファイルシステム要求だけについて登録する。このために、登録の一部として、各フィルタドライバは、フィルタマネージャに、関係する入出力要求のタイプ（たとえば、作成、読取、書込、クローズなど）について通知する。たとえば、暗号化フィルタドライバは、読み取りＩＲＰおよび書き込みＩＲＰについて登録することができるが、データの暗号化または暗号化解除を必要としないＩＲＰについては登録しない。同様に、割り当てフィルタは、ファイル作成およびファイル書込だけに関係する可能性がある。その結果、フィルタドライバが、登録した入出力だけを見るので、このモデルはスタック式フィルタモデルより効率的である。
【００３５】
ボリュームへのアタッチを可能にするために、本発明のモデルでは、フィルタドライバの「インスタンス（instance）」（および以下で説明するボリュームコンテキストも）という概念が定義される。具体的に言うと、ボリュームへのアタッチを望むフィルタドライバは、新しいボリュームがマウントされる時に、インスタンスセットアップ通知を介して通知される。類似する通知が、フィルタドライバがロードされる前に既にマウントされていたボリュームについても提供される。フィルタドライバは、以下で説明するように、登録を介してボリュームにアタッチすることを選択でき、そうする場合に、インスタンスオブジェクトが、アタッチのインスタンスを表すのに使用される。フィルタドライバは、ボリュームディスマウントの時に、同様にすなわち、インスタンスデタッチ通知を介して通知される。本発明のモデルは、またフィルタドライバを、マウントされたボリュームから動的にデタッチする（切り離す）のを可能にする。
【００３６】
本願発明の関連出願である「ソフトウエアモジュールの決定論的順序付けの方法およびシステム」という名称の米国特許出願第０９／７６８，０９８号に一般的に記載されたように、フイルタドライバをコールバック順序のどこにそのドライバが配置されているかを示す高度（altitude）と関連付けることができる。さらに、図３からわかるように、フィルタドライバを、同一ボリュームに複数回アタッチし、アタッチごとにインスタンスを作成することができる（それを行うためには、同一ボリュームの各インスタンスが、順序番号またはオーバーライド機構のいずれかによって、異なる高度である必要がある）。
【００３７】
図３に、複数のインスタンスを有するフィルタの例を示す。図３では、フィルタＡ、たとえば「ファイルシステムアクティビティ（活動）モニタリング（監視）」フィルタが、ファイル入出力を監視し、２つのインスタンス、フィルタＡおよびフィルタＡ’を有する。この形で、ファイルアクティビティ監視製品が、中間（たとえばアンチウィルス）フィルタＢに行く入出力を（フィルタＡを介して）観察すると同時に、最終的に中間フィルタを介してファイルシステムに進む入出力を（フィルタＡ’を介して）観察できるようになる。たとえば、ファイルアクティビティ監視製品に、以下で説明するメッセージを介してフィルタＡおよびフィルタＡ’の両方が報告するユーザモードプログラム（別々には図示せず）を含めることができる。
【００３８】
したがって、ボリュームごとのフィルタドライバインスタンスに、各インスタンスがそのボリュームに関してどこに配置されるかを決定する高度を関連付けることができる。高度は、上記の米国特許出願第０９／７６８，０９８号に記載されたように、所与のフィルタインスタンスに事前に割り当てることができ、かつ／またはフラグ機構または類似物（以下で説明する）を使用して、フィルタの適切な高度を導出することができる。たとえば、アンチウィルスフィルタを、暗号化フィルタとベースファイルシステムの間に割り振ることを可能にしてはならない。というのは、アンチウィルスフィルタが、暗号化の前の元の形のデータを見る必要があるからである。フラグによって、フィルタが、データを観察するか（たとえばアンチウィルスフィルタの）、データを修正するか（たとえば暗号化フィルタの）などを示すことができ、このフラグから高度を導出することができる。この形で、コールバック順序が、ドライバがロードされる順序に基づくのではなく、ある所定の論理的基礎に基づくものになる。
【００３９】
本発明の１つの態様によれば、フィルタドライバは、２種類のコールバックすなわち、プリコールバック（前コールバック）およびポストコールバック（後コールバック）を登録する。プリコールバックは、入出力の下りで、すなわち、ファイルシステムに向かう途中で呼び出され、ポストコールバックは、入出力の完了期間中に、ファイルシステムから入出力マネージャに戻る途中で呼び出される。
【００４０】
効率のために、どのフィルタドライバがどのタイプのコールバックを登録したかを追跡し、これによって、入出力（たとえばＩＲＰ）が受け取られる時にどのフィルタドライバを呼び出すかを効率的に判定するために、フィルタマネージャ２１２は、１つまたは複数のボリュームごとのデータ構造体を維持する。たとえば、図４に示されているように、フィルタインスタンスが、フィルタマネージャ２１２の登録機構４０２に登録する（たとえば、関数を呼び出すことによって）時に、登録機構は、順序付け機構４０４を介して、プリコールバック順序のどこにフィルタインスタンスが属するかを判定する。順序付け機構４０４は、高度の単純な比較に基づくものとするか、順序付け機構４０４に、フィルタインスタンスがどこにおさまるかを判定するためにフラグを評価する論理を含めることができる。どの場合でも、ボリュームごとのコールバックノードが、維持され、その中に登録情報がある。
【００４１】
以下で説明するように、登録時にフィルタマネージャに送られる情報の一部に、フィルタインスタンスがプリコールバックを求めるファイルシステム要求のリストが（たとえば配列内に）含まれる。この情報は、ボリュームごとの順序付きリスト４０８（たとえばボリュームｃ：）または４１０（たとえばボリュームｄ：）あるいは類似物を構成するのに使用され、このリストによって、フィルタマネージャ２１２のコールバック機構４１２が、各インスタンスの呼出しの順序を効率的に判定することができる。たとえば、図４からわかるように、ｃ：ボリュームのファイルの読み取り要求が受け取られる場合に、読取（ＩＲＰのＩＲＰメジャーコードによってインデクシングされる）に関係するフィルタインスタンスが、すばやく入手され、たとえば、図４の例に示されているように、フィルタインスタンスＡ、フィルタインスタンスＢ、フィルタインスタンスＡ’が、プリコールバック順序になる。これが非常に効率的であり、動的登録も容易になることに留意されたい。新しいフィルタインスタンスが登録される時にはいつでも、登録機構が、適切にリストを再構築することができる。
【００４２】
この形で、プリコールバック順序が、ファイル入出力要求のタイプごとに判定されるが、以下で説明するように、各フィルタインスタンスによって返されるステータスが、コールバックを受け取る実際のフィルタインスタンスに影響し、たとえば、フィルタがコールバックに失敗する場合がある。ポストコールバックは、本質的に逆の順序で働くが、以下で説明するように、呼び出されたインスタンスがプリコールバックで返すことができるステータス値の１つが、ポストコールバックなしの成功であり、この場合に、フィルタマネージャ２１２は、そのインスタンスについてポストコールバックをスキップする。
【００４３】
フィルタインスタンスがコールバックに応答して返すことができるステータス値には、一般に、コールバックなしの成功、コールバックありの成功、保留、同期、完了、および高速入出力却下が含まれる。１特定の実施形態では、「ＦＬＴ＿ＰＲＥＯＰ＿ＳＵＣＣＥＳＳ＿ＮＯ＿ＣＡＬＬＢＡＣＫ」によって、入出力パススルーの処理が継続され、ステータス「ＦＬＴ＿ＰＲＥＯＰ＿ＳＵＣＣＥＳＳ＿ＷＩＴＨ＿ＣＡＬＬＢＡＣＫ」もそうであるが、さらに、この入出力が完了する時に完了コールバックが要求される。フィルタは、ＦＬＴ＿ＰＲＥＯＰ＿ＰＥＮＤＩＮＧも指定することができるが、この場合には、フィルタがその後にＦｌｔＣｏｍｐｌｅｔｅＰｅｎｄｅｄＰｒｅＯｐｅｒａｔｉｏｎ（）を呼び出すまで入出力がホールドされる。ＦＬＴ＿ＰＲＥＯＰ＿ＳＹＮＣＨＲＯＮＩＺＥでは、入出力の完了を待ち、元のスレッドコンテキストでポストコールバックを呼び出す。入出力同期化は、フィルタマネージャによって処理される。「保留」および「同期」は、高速入出力では返すことができないことに留意されたい。ＦＬＴ＿ＰＲＥＯＰ＿ＣＯＭＰＬＥＴＥでは、成功または失敗のステータスコードのいずれかで入出力が完了する（一般に、レガシディスパッチのＩｏＣｏｍｐｌｅｔｅＲｅｑｕｅｓｔに似る）。ＦＬＴ＿ＰＲＥＯＰ＿ＤＩＳＡＬＬＯＷ＿ＦＡＳＴ＿ＩＯは、高速入出力に限って有効であり、一般に、レガシディスパッチでＦＡＬＳＥを返すことと同等である。
【００４４】
この形で、管理されるフィルタドライバモデルを用いて、フィルタドライバが、プリコールバックルーチンからの戻りステータスを介して入出力の実行パスを制御できるようになる。これによって、フィルタドライバが、保留する、完了する、下位フィルタに渡す、ポストコールバックを要求する、「同期化された」ポストコールバックを要求するなど、異なる形で入出力の処理を要求できるようになる。
【００４５】
本明細書に記載のとおり、フィルタインスタンスは、ポストコールバックに関して登録される。ポストコールバックに応答して、フィルタインスタンス（たとえば、前にＦＬＴ＿ＰＲＥＯＰ＿ＳＵＣＣＥＳＳ＿ＷＩＴＨ＿ＣＡＬＬＢＡＣＫのステータスを返したもの）が、ＦＬＴ＿ＰＯＳＴＯＰ＿ＦＩＮＩＳＨＥＤ＿ＰＲＯＣＥＳＳＩＮＧのステータスを返して、入出力完了を継続するか、ＦＬＴ＿ＰＯＳＴＯＰ＿ＭＯＲＥ＿ＰＲＯＣＥＳＳＩＮＧ＿ＲＥＱＵＩＲＥＤのステータスを返して完了を打切り、後にＦｌｔＣｏｍｐｌｅｔｅＰｅｎｄｅｄＰｏｓｔＯｐｅｒａｔｉｏｎ（）関数を呼び出すことによって入出力を完了することができる。フィルタは、ハンドラを再解析するためのＦｌｔＲｅｉｓｓｕｅＳｙｎｃｈｒｏｎｏｕｓＩｏ（）関数呼出しを介して動作後の処理（post-operation processing）中に入出力を再発行することができる。ＦＬＴ＿ＰＯＳＴＯＰ＿ＵＮＤＯ＿ＣＲＥＡＴＥステータスは、作成要求をエラーにすることによってファイルオープンをブロックすることを望むフィルタのために設けられる。
【００４６】
入出力完了は、プリコールバックでフィルタインスタンスが見るパラメータが、ポストコールバックの時と同一になることを保証する形で、フィルタマネージャ２１２によって処理される。これが、フィルタがしばしばパラメータ、バッファポインタなどを変更し、多数の問題につながるレガシスタック式モデルに対する改善であることに留意されたい。一般に、これは、図５に示されているように実行され、フィルタマネージャが、インスタンスごとに完了ノードを維持する（すなわち、少なくともコールバックを受け取るインスタンスごとに）。
【００４７】
本質的に、コールバックを（そのステータスを介して）要求した、プリコールバックで呼び出されるインスタンスごとに、フィルタマネージャは、各プリコールバックの前のパラメータのスナップショットをとり、スナップショットを完了ノードに保管し、完了ノードをスタック５０２にプッシュする。ポストコールバックデータを管理するために、ＩＲＰごとに、フィルタマネージャは、フィルタドライバによって見られないＩＲＰＣＴＲＬヘッダ５０４を維持し、このＩＲＰＣＴＲＬヘッダ５０４によって、デバイスオブジェクト、ＩＲＰポインタ、完了ノードのサイズおよびそれに対応するインスタンスを含むノード情報などの情報が追跡される。その後、ポストコールバック中に、フィルタマネージャが、本質的に、逆方向に進み、各完了ノードをスタック５０２からポップし、完了ノードデータをそのインスタンスのコールバックデータ５０６に入れ、これによって、パラメータを復元する。フィルタインスタンスが、その順序でプリコールされる前に動的に登録される場合に、スタックを、追加の完了ノードと共に別のスタックにコピーすることができ、所与のＩＲＰのプリコール順序でプリコールが既に渡された後で登録される場合には、そのインスタンスをコールバックしてはならないことに留意されたい。
【００４８】
効率のために、スタックは、フィルタインスタンスがコールバックを受け取る時と、フィルタインスタンスがコールバックデータに対する変更を行う時だけ完了ノードをスタックにプッシュさせる必要がある。というのは、そうでない場合に、同一の完了ノードを再利用できるからである。フィルタインスタンスは、データを修正する時に、「ダーティ(dirtied:汚染)」パラメータフラグをセットする責任を負う。そうしない場合に、その変更が破棄され、変更されたデータのスナップショットがとられず、これによって、すべての変更が、別のドライバに見えなくなることに留意されたい。
【００４９】
図２に戻って、最後のポストコールバックが行われた後に、フィルタマネージャ２１２は、コールバックデータをＩＲＰに再変換（マーシャル）し、すべての上位レガシフィルタ２１０を介して、スタックのＩＲＰを入出力マネージャ２０６に向かって返す。諒解されるとおり、この管理されるフィルタモデルでは、レガシモデルの短所の多数が、除去されるか大幅に減らされる。
【００５０】
上記の機能のほかに、フィルタマネージャは、フィルタが共通して必要とする機能を提供する豊富なＡＰＩセットも提供する。たとえば、ある種のフィルタは、それ自体で入出力を実行することを必要とし、たとえば、アンチウィルスフィルタは、オープンされる前にファイルを読み取ろうとする可能性がある。フィルタドライバは、それ自体の入出力オペレーションを開始することを望む時に、まず、ＦｌｔＡｌｌｏｃａｔｅＣａｌｌｂａｃｋＤａｔａ（）を呼び出す。この関数によって、ＦＬＴ＿ＣＡＬＬＢＡＣＫ＿ＤＡＴＡ構造体が割り振られ、返され、フィルタは、この構造体に関連データフィールドを移植する。ＦｌｔＡｌｌｏｃａｔｅＣａｌｌｂａｃｋＤａｔａが、本質的に、レガシシステムでのＩｏＡｌｌｏｃａｔｅＩｒｐ（）呼出しの置換であることに留意されたい。フィルタは、入出力要求を残りのフィルタ、レガシフィルタ、およびベースファイルシステムに送る準備ができた時に、ＦｌｔＰｅｒｆｏｒｍＳｙｎｃｈｒｏｎｏｕｓＩｏ（）またはＦｌｔＰｅｒｆｏｒｍＡｓｙｎｃｈｒｏｎｏｕｓＩｏ（）（ＩｏＣａｌｌＤｒｉｖｅｒ（）に似る）を呼び出す。デフォルトで、フィルタが開始する入出力は、所与のボリュームに関して次にアタッチされたフィルタに送られ、入出力を開始するフィルタの上位にアタッチされたフィルタが迂回される。しかし、階層ストレージ管理（ＨＳＭ）フィルタがそうすることを必要とするので、入出力をシステム内のどのデバイスにも送ることが可能である。
【００５１】
もう１つの例として、フィルタは、時々、ファイルを作成することを必要とし、ＦｌｔＣｒｅａｔｅＦｉｌｅ（）関数が、入出力初期化の開始点として提供される。この関数は、ファイルハンドルをとる既存のオペレーティングシステムＡＰＩと共に使用することができるハンドルを返し、他の場合にファイル作成を可能にする。この関数は、共有アクセスオーバーライドをサポートする。さらに、フィルタマネージャは、すべてのコールバックが、動的に挿入されるものを含めて、要求元フィルタより下のフィルタだけによって見られることを保証し、これによって、諒解されるであろうとおり、再帰コールバックを防ぐ。このために、フィルタマネージャは、インスタンスヒントを用いてファイルを作成し、このヒントを使用して、要求元フィルタを識別する。マウントポイントオープンが、コールバックスタックの最上部に行く必要があるので、例外であることに留意されたい。
【００５２】
ＦｌｔＲｅａｄＦｉｌｅ（）を用いると、入出力完了時に発行される、フィルタが供給するコールバックを有する、同期入出力および非同期入出力が可能になる。ＦｌｔＷｒｉｔｅＦｉｌｅ（）、ＦｌｔＳｅｔＩｎｆｏｒｍａｔｉｏｎＦｉｌｅ（）などが、類似するセマンティクスを有する。ＦｌｔＡｌｌｏｃａｔｅＣａｌｌｂａｃｋＤａｔａ（）を用いると、入出力完了コールバックを受け入れるＦｌｔＰｅｒｆｏｒｍＳｙｎｃｈｒｏｎｏｕｓＩｏ（）またはＦｌｔＰｅｒｆｏｒｍＡｓｙｎｃｈｒｏｎｏｕｓＩｏ（）を含めて、入出力をカスタマイズできるようになる。
【００５３】
コンテキスト管理は、フィルタマネージャが提供するＡＰＩが非常に有益である場合のもう１つの例である。というのは、フィルタが、コンテキスト構造体を各ストリームハンドル、ストリーム、インスタンス、およびボリュームに関連付けることを必要とすることがしばしばであるからである。たとえば、フィルタは、コンテキストを使用して、フィルタが入出力をインターセプトする時にルックアップされるハンドルごと／ストリームごと／ファイルごと／ボリュームごと／インスタンスごとの情報を保管する。フィルタがあるエンティティに対してセットするコンテキストのすべてが、フィルタが、たとえばＡＰＩを介して、それを要求する時に、フィルタに渡される。コンテキストの寿命は、フィルタマネージャ２１２によって管理され、フィルタは、適切なオブジェクト（ストリーム／ファイル／インスタンス／ボリュームなど）が削除されることに起因してコンテキストが削除される時に、コールバックされる。
【００５４】
本発明のもう１つの態様によれば、フィルタマネージャ２１２は、各フィルタのコンテキストデータ（たとえばポインタまたは類似物）を適切なオブジェクト、すなわちストリームハンドル、ストリーム、ファイル、インスタンス、またはボリュームについて保管するための効率的なコンテキストサポートを提供する。この目的のために、本発明は、エンティティにコンテキストを返すＡＰＩの組を介して、コンテキストサポートを提供し、したがって、フィルタごとのコンテキストのそのエンティティへの関連付けを単純にする。コンテキストは、いつでもセットし、かつ／またはリセットすることができる。本発明は、インスタンスについて通知をセットアップするコールバックの組を介する、インスタンスに関する通知サポートも提供する。
【００５５】
エンティティのタイプには、インスタンス、ボリューム（ローカルディスクボリュームまたはリモートネットワーク共有）、ストリーム（ファイルごとに複数のストリームをサポートするファイルシステムの場合）、ストリームハンドル（ファイルオブジェクトごと）、およびファイル（たとえば、ファイルのすべてのストリーム）が含まれる。インスタンスに関して、上で説明したように、フィルタがボリュームにアタッチされる時に、インスタンスが作成され、やはり上で説明したように、たとえば同一ボリュームの別のフィルタの上と下の両方にアタッチされるなど、所与のボリュームについて所与のフィルタの複数のインスタンスが存在することができる。各インスタンスは、たとえばそのインスタンスのプライベートログをポイントするために、コンテキストを関連付けられる。ボリュームコンテキストを、フィルタインスタンスの間で共有することができる。
【００５６】
コンテキストをオブジェクトに関連付けるために、フィルタは、コンテキストのタイプ（ストリームハンドル、ストリーム、ファイル、インスタンス、またはボリューム）、コンテキストのサイズ、およびコンテキストをページプールメモリまたは非ページプールメモリから割り振らなければならないかどうかを指定して、ＦｌｔＡｌｌｏｃａｔｅＣｏｎｔｅｘｔ（）を呼び出す。コンテキストが割り振られ、初期化されたならば、フィルタは、適切なルーチン：ＦｌｔＳｅｔＳｔｒｅａｍＨａｎｄｌｅＣｏｎｔｅｘｔ（）、ＦｌｔＳｅｔＳｔｒｅａｍＣｏｎｔｅｘｔ（）、ＦｌｔＳｅｔＦｉｌｅＣｏｎｔｅｘｔ（）、ＦｌｔＳｅｔＩｎｓｔａｎｃｅＣｏｎｔｅｘｔ（）、またはＦｌｔＳｅｔＶｏｌｕｍｅＣｏｎｔｅｘｔ（）を呼び出すことによってコンテキストをオブジェクトに関連付ける。
【００５７】
図６からわかるように、ファイル、ストリーム、およびストリームハンドルに関連するフィルタインスタンスを効率的にルックアップするために、フィルタマネージャ２１２は、ファイルオブジェクトに関連するデータ構造体にツリー（たとえばスプレイ木）を追加する。具体的に言うと、オペレーティングシステムは、ストリームへの任意のコンテキストの追加を容易にし、フィルタマネージャ２１２は、この機構を使用して、ストリーム制御リスト６０８およびツリー６１０をＦＳＲＴＬ＿ＡＤＶＡＮＣＥＤ＿ＦＣＢ＿ＨＥＡＤＥＲ  ６１２（本質的に、ファイルオブジェクト６１４によってそのコンテキスト６１６を介してポイントされる）に追加する。ツリー６１０の各ノードが、このストリームに関連するコンテキストを有するフィルタインスタンスを表す。別々に図示はされていないが、必要になる可能性がある異なるタイプのアクセスに関するフィルタインスタンスによる指定に従って、ページプールメモリと非ページプールメモリに関する並列のツリーを設けることができる。
【００５８】
所与のストリームハンドルについて、ツリーの各ノードが、１つのキーとしてファイルオブジェクト、もう１つのキーとしてインスタンスを含むキーによってアクセスされる。ストリームの場合に、ファイルオブジェクトキーがＮＵＬＬであることに留意されたい。図７からわかるように、フィルタマネージャ２１２内の（またはそれに関連する）コンテキスト機構４１２への関数呼出しのデータを介するなど、これらのキーを与えられた時に、ツリー６１０内の適切なノードの所在を、フィルタドライバインスタンス７０２についてすばやく突き止めることができ、適切なコンテキスト７０４（たとえばコンテキストポインタの形で）が、要求元のフィルタドライバインスタンス７０２に返される。一般に、所与の構成で多数のフィルタインスタンスが存在しないので、部分的に、トラバーサルは高速である。
【００５９】
一実施形態で、フィルタが、インスタンスの通知を受け取ることができる。
【００６０】
【表１】
2004192648.tif 000003
【００６１】
特定のインスタンスについてコンテキストが必要な場合には、このコールバックでセットすることができる。コンテキストは、ＰＶＯＩＤであり、システムは、これを完全に不透明として扱い、したがって、フィルタは、これを使用して、フラグフィールド、カウンタ、ポインタ、または必要なもののどれでも保管することができる。フィルタが、インスタンスコールバックを成功裡に初期化でき、このボリュームに対するアクティビティを監視することを望む場合には、フィルタは、ＳＴＡＴＵＳ＿ＳＵＣＣＥＳＳを返さなければならない。フィルタが、このボリュームに対してこのインスタンスが作成されることを望まない場合には、ＳＴＡＴＵＳ＿ＦＬＴ＿ＤＯ＿ＮＯＴ＿ＡＴＴＡＣＨを返さなければならない。インスタンスの通知クリーンアップコールバックは、新しいオペレーションがボリュームに与えられる時にインスタンス分解を正しく同期化するために設けられ、これには、ＩｎｓｔａｎｃｅＱｕｅｒｙＴｅａｒｄｏｗｎ、ＩｎｓｔａｎｃｅＴｅａｒｄｏｗｎＳｔａｒｔ、およびＩｎｓｔａｎｃｅＴｅａｒｄｏｗｎＣｏｍｐｌｅｔｅが含まれる。
【００６２】
あるエンティティにコンテキスト構造体を提供するフィルタは、そのフィルタに対応するＣｏｎｔｅｘｔＣｌｅａｎｕｐＣａｌｌｂａｃｋを呼び出される。言い換えると、メモリプールのリークを防ぐために、フィルタは、それが割り振ったコンテキストを記憶する必要がない。というのは、システムが、クリーンアップを行わなければならない時を処理するからである。コンテキストを解放しなければならない時には、システムが、フィルタのＣｏｎｔｅｘｔＣｌｅａｎｕｐＣａｌｌｂａｃｋを呼び出す。このコールバック中に、フィルタは、コンテキストの内容を初期化前の状態に戻す責任を負い、リターン時に、システムが、フィルタの以前のＦｌｔＡｌｌｏｃａｔｅＣｏｎｔｅｘｔ（）呼出しによって割り振られたメモリを解放する。クリーンアップは、成功すると仮定され、したがって、値を返す必要はない。システムは、コンテキストクリーンアップルーチンが、プール解放を安全に行うのに十分に低いＩＲＱＬで呼び出されることも保証する。
【００６３】
インスタンスコンテキストは、フィルタがボリュームからデタッチされる時にクリーンアップされる。ボリュームコンテキストは、ボリュームがディスマウントされた後、そのボリュームのすべてのファイル、ストリーム、およびストリームハンドルがクリーンアップされた後にクリーンアップされる。メモリマネージャ、キャッシュマネージャ、およびファイルシステム実施の詳細に起因して、ボリュームコンテキストが、ボリュームがディスマウントされた後に比較的長時間にわたってクリーンアップされない場合がある。
【００６４】
ファイルコンテキストは、ファイルシステムがファイルに関連するメモリを解放する時にクリーンアップされるが、これは、複数ストリームファイルシステムでは、そのファイルの最後のストリームの最後のストリームハンドルが解放された後になる。オペレーティングシステムのメモリマネージャおよびキャッシュマネージャが、ファイルの１つまたは複数のストリームへの参照をまだ有する可能性があるので、ファイルコンテキストが、ストリームへの最後のユーザハンドルがクローズされた後に比較的長時間クリーンアップされない場合があることに留意されたい。同様に、ストリームコンテキストは、ファイルシステムがストリームに関連するメモリを解放する時にクリーンアップされるが、これは、そのストリームに関する最後のストリームハンドルが解放された後になる。やはり、オペレーティングシステムのメモリマネージャおよびキャッシュマネージャが、ファイルの１つまたは複数のストリームへの参照をまだ有する可能性があるので、ストリームコンテキストが、ストリームへの最後のユーザハンドルがクローズされた後に比較的長時間クリーンアップされない場合がある。
【００６５】
ストリームハンドルコンテキストは、ストリームハンドルへの最後の参照が解放される時にクリーンアップされる。これは、ユーザハンドルがクローズされた結果であるか、最後のメモリマネージャ参照またはキャッシュマネージャ参照が解放された結果である可能性がある。
【００６６】
コンテキストを、オブジェクトが現在コンテキストを有しない場合にセットすることができ、あるいは、コンテキストを変更することができる。フィルタは、ルーチン、ＦｌｔＤｅｌｅｔｅＣｏｎｔｅｘｔ（）、ＦｌｔＤｅｌｅｔｅＶｏｌｕｍｅＣｏｎｔｅｘｔ（）、ＦｌｔＤｅｌｅｔｅＩｎｓｔａｎｃｅＣｏｎｔｅｘｔ（）、ＦｌｔＤｅｌｅｔｅＦｉｌｅＣｏｎｔｅｘｔ（）、ＦｌｔＤｅｌｅｔｅＳｔｒｅａｍＣｏｎｔｅｘｔ（）、およびＦｌｔＤｅｌｅｔｅＳｔｒｅａｍＨａｎｄｌｅＣｏｎｔｅｘｔ（）の１つを使用して、コンテキストをクリアすることができる。
【００６７】
しばしば、フィルタは、あるエンティティに関係するかどうかを判断するために、エンティティに関する基本的な情報を求める。ボリュームの場合に、この情報は、ファイルシステム、ボリュームがローカルまたはリモートのどちらか、取外し可能メディアであるかどうか、などである可能性がある。ファイルの場合には、ファイの名前、タイムスタンプ、サイズ、拡張子などが含まれる可能性がある。システムは、この情報を便利に検索する関数（たとえば、ＦｌｔＧｅｔＦｉｌｅＩｎｆｏｒｍａｔｉｏｎ（）、ＦｌｔＧｅｔＶｏｌｕｍｅＩｎｆｏｒｍａｔｉｏｎ（））を公開することができる。フィルタは、ファイルの再解析点をセットするために、ＦｌｔＴａｇＦｉｌｅ（）の呼出しを望む場合もある。
【００６８】
本発明のアーキテクチャによって提供されるもう１組のＡＰＩは、フィルタインスタンスとユーザモードコードの間の通信の促進を対象とする。具体的に言うと、多くのフィルタが、通常は製品の管理コンポーネントである、ユーザモードサービスの対応物を有し、フィルタは、このサービスと通信することを必要とする。本発明のアーキテクチャは、これらの製品が、カーネル開始通信（kernel-initiated communication）と同様にユーザモードによって開始される通信の両方を使用するためのＡＰＩを提供することができる。
【００６９】
たとえば、ユーザモードコンポーネントと通信するフィルタについて、これらのユーザモードアプリケーションのためのライブラリが使用可能である。このライブラリでは、フィルタのロードおよびアンロード、ボリュームへのフィルタのアタッチおよびデタッチ、フィルタへのユーザモードからの通信チャネルのオープンおよびフィルタからのデータの送受、およびシステムの現在のステータスに関する情報に関するシステムへの照会のルーチンを含むルーチンが公開される。たとえば、ユーザモードプログラムが、どのフィルタが現在ロードされているか、どのインスタンスが所与のボリュームまたは所与のフィルタに対して存在するか、などを照会することができる。フィルタ−ユーザ通信が、フィルタ／インスタンスの列挙、フィルタのアンロード／ロードなどを可能にする、提供される管理ＡＰＩと異なることに留意されたい。というのは、フィルタ−ユーザ通信ＡＰＩが、それ自体のプライベートな通信を行うためにフィルタによって使用されるためのものであるからである。
【００７０】
要約すると、新しいフィルタモデルによって、ダイナミックなロード／アンロード、ボリュームへのダイナミックなアタッチ／デタッチ、柔軟な順序付け、およびフィルタが最も一般的に必要とする豊富なＡＰＩの組へのアクセスを可能にする、信頼性があり効率的なファイルシステムフィルタを記述する形が提供される。以下に、Ｗｉｎｄｏｗｓ（登録商標）ＮＴ／２０００／ＸＰオペレーティングシステムに基づく１つの実施形態の例の具体的な詳細を示す。
【００７１】
実施形態の例
以下では、フィルタマネージャへの登録を含む、関数呼出しを介して実行されるフィルタが開始するオペレーションの一部を説明する。
関係する入出力のコールバックを宣言する。
【００７２】
【表２】
2004192648.tif 000004
【００７３】
登録構造体を宣言する。
【００７４】
【表３】
2004192648.tif 000005
【００７５】
フィルタマネージャに登録する。
【００７６】
【表４】
2004192648.tif 000006
【００７７】
プリコールバックを得る。
【００７８】
【表５】
2004192648.tif 000007
【００７９】
この例の実施形態では、ファイルシステムフィルタドライバに、ＮＴカーネルモードドライバが含まれ、したがって、ＤｒｉｖｅｒＥｎｔｒｙ（）という名前の関数（ドライバがロードされる時に最初に呼び出される関数）をエクスポートする必要がある。ロードされる時に、フィルタは、ＦｌｔＲｅｇｉｓｔｅｒＦｉｌｔｅｒ（）という名前の、ＤｒｉｖｅｒＥｎｔｒｙ（）に登録する関数を呼び出す。ＦｌｔＲｅｇｉｓｔｅｒＦｉｌｔｅｒ（）は、パラメータとしてＦＬＴ＿ＲＥＧＩＳＴＲＡＴＩＯＮ構造体をとるが、この構造体には、（とりわけ）インスタンスセットアップコールバック、インスタンス分解コールバック、コンテキストコールバック関数ポインタのリスト、およびファイルシステムオペレーションのコールバックポインタのリストが含まれる。フィルタが、比較的少数のオペレーションだけをフックすることを望み、あるとしても少数のオブジェクトについてコンテキストをセットすることだけに関係する多くのシナリオでは、このリストが、非常に短くなる可能性があることに留意されたい。
【００８０】
代替実施形態では、フィルタが１つまたは複数のフィルタ属性フラグをセットし、そのフラグから高度を導出することができる、フラグフィールドを設けることができる。たとえば、暗号化フィルタまたは圧縮フィルタが、ベースファイルシステムへの途中およびそれからの途中でデータを修正することをシステムに通知するなど、データを修正するフィルタが、フラグをセットすることができる。この実施形態では、ユーザのデータを複数のストリームに分割するフィルタも、このフラグをセットしなければならない。フィルタは、フィルタがデータを検査することを示すためにもフラグをセットすることができ、たとえば、平文の非圧縮データを見る必要があるウィルスフィルタは、このフラグをセットする。フラグは、標準情報（タイムスタンプおよび日付など）を修正するフィルタ、標準情報を検査する（たとえば、日付に基づいてファイルに対して異なるオペレーションを実行するために）フィルタ、異なる名前のファイル／ストリームに作成をリダイレクトするフィルタ（たとえば、シンボリックリンクフィルタ／ＳＩＳタイプフィルタ）、ファイル名に頼るフィルタ（．ＥＸＥファイルおよび．ＤＯＣファイルをスキャンするウィルスフィルタなど）に関しても、フラグが使用可能である。
【００８１】
上で説明したように、これらのフラグは、システムが正しい順序でボリュームにフィルタをアタッチするのを助けるのに使用することができる。たとえば、アンチウィルスフィルタは、暗号化の前のそのままのデータを見る必要があるので、アンチウィルスフィルタを暗号化フィルタとベースファイルシステムの間にアタッチできてはならない。これを防ぐために、モデルは、フィルタがデータを検査することを示すフラグをセットされたフィルタが、フィルタがデータを修正することを示すフラグをセットされたフィルタの上にアタッチされることを許容しない。さらに、これらのフラグのある組合せを使用して、フィルタがアタッチされなくすることができ、たとえば、２つのフィルタが、各フィルタがデータの検査および修正の両方を行うことを示すフラグをセットした場合に、両方のフィルタを同一ボリュームに安全にアタッチする順序はない。
【００８２】
下に、ファイルシステムフィルタドライバのタイプの１つの論理的な順序付けを示す。
【００８３】
【表６】
2004192648.tif 000008
【００８４】
【表７】
2004192648.tif 000009
【００８５】
上で説明したように、コールバックデータは、フィルタドライバへのオペレーションを記述する必要な情報を表すための、ＩＲＰに多少似た、入出力表現の単位である。コールバックデータには、ファイルシステムフィルタの使用のために特殊化され、高速入出力、ＩＲＰ、およびＦｓＦｉｌｔｅｒについて存在する正規化されたパラメータが含まれる。変更可能なパラメータセクションは、ドライバによって修正する（すなわち、ダーティにする）ことができ、パラメータセクションは、上で説明した完了ノードスタックポップオペレーションを介して、フィルタからフィルタへ、フィルタマネージャによって引き受けられる。
【００８６】
下記は、コールバックデータ構造体の例である。
【００８７】
【表８】
2004192648.tif 000010
【００８８】
下記は、入出力パラメータブロックの例である。
【００８９】
【表９】
2004192648.tif 000011
【００９０】
動作前（pre-operation）のコールバックは、同一のシグニチャを有する。
【００９１】
【表１０】
2004192648.tif 000012
【００９２】
上で説明したように、動作前のコールバックは、ＦＬＴ＿ＰＲＥＯＰ＿ＣＡＬＬＢＡＣＫ＿ＳＴＡＴＵＳについて、下記のステータス（および他のステータス）の１つを返すことができる。
【００９３】
【表１１】
2004192648.tif 000013
【００９４】
動作後のコールバック(post-operation callbacks)は、同一のシグニチャを有する。
【００９５】
【表１２】
2004192648.tif 000014
【００９６】
フラグに、下記を含めることができる。
【００９７】
【表１３】
2004192648.tif 000015
【００９８】
ＦＬＴ＿ＰＯＳＴＯＰ＿ＣＡＬＬＢＡＣＫ＿ＳＴＡＴＵＳ：
【００９９】
【表１４】
2004192648.tif 000016
【０１００】
フィルタは、動作前のコールバックごとに完了コールバックを受け取る。たとえば、プリコールバックでメモリが割り振られる場合に、フィルタは、完了コールバックでそれを解放する機会を与えられることと、完了コールバックが、複数回呼び出されず、フィルタがメモリを複数回解放することがないことを保証することができる。
【０１０１】
プリコールバックおよびポストコールバックを提供できるオペレーションに、ＩＲＰ＿ＭＪ＿ＣＲＥＡＴＥからＩＲＰ＿ＭＪ＿ＰＮＰまでの既存の  ＩＲＰ＿ＭＪ＿コード、ＩＲＰ同等物がない、高速入出力オペレーションを表すために作成されるＩＲＰ＿ＭＪコード、およびＦＳフィルタオペレーションを表すために作成されるＩＲＰ＿ＭＪコードが含まれる。将来のオペレーティングシステムバージョンで、新しいＩＲＰ＿ＭＪ＿コードが追加される場合に、既存フィルタは、影響を受けず、フィルタがコンパイルされた時に存在しなかったＩＲＰ＿ＭＪ＿ルーチンからのコールバックを一切受け取らない。フィルタが、オペレーティングシステムが認識しないＩＲＰ＿ＭＪ＿コードに登録する場合には、ＦｌｔＲｅｇｉｓｔｅｒＦｉｌｔｅｒ（）が、特殊な成功ステータスを返し、そのバージョンに存在する関数のコールバックだけが呼び出される。フィルタが、１つまたは複数のコールバックが提供されない場合に実行の継続を求めない場合には、フィルタは、ＦｌｔＵｎｒｅｇｉｓｔｅｒＦｉｌｔｅｒ（）を呼び出すことができる。
【０１０２】
ＩＲＰ＿ＭＪ＿ＲＥＡＤおよびＩＲＰ＿ＭＪ＿ＷＲＩＴＥのコールバックが、ＩＲＰベースの入出力および高速入出力について呼び出されることに留意されたい。ＩＲＰ＿ＭＪ＿ＣＲＥＡＴＥのプリコールアウトは、ファイルまたはストリームのコンテキストを渡されない。というのは、どのようなファイルまたはストリーム（ある場合）が作成されるかが、作成の前にはまだ決定されていないからである。ＩＲＰ＿ＭＪ＿ＣＬＯＳＥのポストコールアウトは、コンテキストを一切渡されない。というのは、コンテキストが関連付けられるシステム内部の構造体が、クローズ後のルーチンが呼び出された前に解放されるからである。ＩＲＰ＿ＭＪ＿ＣＬＥＡＮＵＰおよびＩＲＰ＿ＭＪ＿ＣＬＯＳＥのプリコールバックは、成功し、ＦＬＴ＿ＰＲＥＯＰ＿ＳＵＣＣＥＳＳ＿ＷＩＴＨ＿ＣＡＬＬＢＡＣＫまたはＦＬＴ＿ＰＲＥＯＰ＿ＳＵＣＣＥＳＳ＿ＮＯ＿ＣＡＬＬＢＡＣＫを返さなければならない。
【０１０３】
動作後のコールバックは、ＤＰＣレベルで呼び出される可能性を有し、したがって、リソースまたはミューテックスを待ってはならず、待つ関数を呼び出してはならない。ＦｌｔＳｅｔＦｉｌｅＣｏｎｔｅｘｔ（）などのルーチンが、リソースを獲得し、したがって、動作後のコールバックから呼び出すことができないことに留意されたい。
【０１０４】
上で説明したように、ポストコールバックは、ＦＬＴ＿ＰＯＳＴＯＰ＿ＳＴＡＴＵＳ＿ＳＵＣＣＥＳＳまたはＦＬＴ＿ＰＯＳＴＯＰ＿ＭＯＲＥ＿ＰＲＯＣＥＳＳＩＮＧ＿ＲＥＱＵＩＲＥＤを返す。ポストコールバックは、ＩｏＳｔａｔｕｓにエラーコードをセットすることによってエラーになることができ、一般的な規則として、行われたことを元に戻すのは、フィルタの責任である。
【０１０５】
フィルタインスタンスの動的登録のほかに、フィルタインスタンスを動的にデタッチすることができ、これによって、そのフィルタインスタンスが、そのボリュームに対する動作に関してそれ以上呼び出されなくなる。フィルタのアンロードは、本質的に、そのコードがそれ以上メモリに存在しなくなることを意味する。これは、システムシャットダウン時と、システムをシャットダウンせずにフィルタの新しいバージョンがインストールされる時に、最も頻繁に行われる。フィルタインスタンスを、未解決の入出力がある時でもデタッチできることに留意されたい。その場合には、フィルタの１つまたは複数の完了ルーチンが、未解決の入出力オペレーションについて、フラグＦＬＴＦＬ＿ＰＯＳＴ＿ＯＰＥＲＡＴＩＯＮ＿ＤＲＡＩＮＩＮＧをセットして呼び出される。フィルタは、これらの入出力オペレーションが実際に完了する時に、完了コールバックを受け取らない。フィルタインスタンスがデタッチされる時に、システムは、そのインスタンスに関連するファイルオブジェクト、ストリームオブジェクト、およびストリームファイルオブジェクトの未解決のコンテキストについて、フィルタのコンテキストを解放するルーチンを呼び出す。
【０１０６】
前述の詳細な説明からわかるとおり、入出力処理要件の多くを処理し、これによってより単純で信頼性のあるフィルタドライバを容易にする、管理されるフィルタドライバアーキテクチャが提供される。ドライバを、関係する入出力だけについて選択的に登録することができ、効率が改善される。動的なロードおよびアンロード、アタッチおよびタッチが達成される。他の利益には、複数ストリーム機能を有するファイルシステムでのコンテキスト管理を含むコンテキスト管理が含まれる。したがって、この方法およびシステムは、現代のコンピュータで必要な重要な長所および利益を提供する。
【０１０７】
本発明は、さまざまな修正および代替構成を許すが、本発明のいくつかの例示の実施形態を、図面に示し、上で詳細に説明した。しかし、本発明を、開示された特定の形態に限定する意図はなく、逆に、本発明が、本発明の趣旨および範囲に含まれる修正形態、代替の構成、および同等物のすべてを含むことを理解されたい。
【産業上の利用可能性】
【０１０８】
本発明により、非再入可能ファイル入出力などのフィルタの効率的なコンテキスト管理およびその他の機能が、提供される。
【図面の簡単な説明】
【０１０９】
【図１】本発明を組み込むことができるコンピュータシステムを概略的に表わすブロック図である。
【図２】本発明の態様による、フィルタへの入出力を管理するコンポーネントを含むアーキテクチャを概略的に表わすブロック図である。
【図３】本発明の態様による、管理されるフィルタのインスタンスを概略的に表わすブロック図である。
【図４】本発明の態様による、適切に登録されたフィルタに入出力を選択的に渡すためにフィルタマネージャによって使用されるデータ構造体を概略的に表わすブロック図である。
【図５】本発明の態様による、ポストコールバックオペレーションで登録されたフィルタドライバにコールバックデータを返す完了ノードのスタックを表す図である。
【図６】本発明の態様による、どのインスタンスがコンテキストデータを有するかの効率的な判定のためのツリーを表すブロック図である。
【図７】本発明の態様による、コンテキストデータをフィルタドライバに返すステップを表すブロック図である。
【符号の説明】
【０１１０】
１２０  処理ユニット
１２１  システムバス
１３０  システムメモリ
１３１  ＲＯＭ
１３２  ＲＡＭ
１３３  ＢＩＯＳ
１３４，１４４  オペレーティングシステム
１３５          ファイルシステム
１３６，１４５  アプリケーションプログラム
１３７，１４６  他のプログラムモジュール
１３８，１４７  プログラムデータ
１４０，１５０  取外し不能不揮発性メモリインターフェース
１６０  ユーザ入力インターフェース
１７０  ネットワークインターフェース
１７１  ローカルエリアネットワーク
１７２  モデム
１７３  広域ネットワーク
１８０  リモートコンピュータ
１８５  リモートアプリケーションプログラム
１９０  ビデオインターフェース
１９４  出力周辺インターフェース
２０２  アプリケーション
２０４  ＡＰＩ
２０６  入出力マネージャ
２０８  フィルタドライバスタック
２１０  レガシフィルタドライバ
２１２  ＦＳフィルタマネージャ
２７６  ローカルまたはリモートのファイルシステム（たとえばＮＴＦＳ）
２７６  ローカルまたはリモートのファイルシステム（たとえばＮＴＦＳ）
４０２  登録機構
４０４  順序付け機構（Ａ、Ｂ、Ａ’、Ｃ、Ｄ、Ｅ）
４０６  コールバックノード
４０８  プリコールバック、Ｃ：に関係
４１０  プリコールバック、Ｄ：に関係
４１２  コールバック機構（コンテキスト機構）
５０２  完了ノード
５０４  ＩＲＰＣＴＲＬ
５０６  コールバックデータ
６０８  ストリームリスト制御
６１０  フィルタノードツリー
６１２  ＦＣＢヘッダ
６１４  ファイルオブジェクト
６１６  ＦＳコンテキスト
７０２  フィルタドライバインスタンス
７０４  コンテキスト
【図１】
2004192648.tif 000017
【図２】
2004192648.tif 000018
【図３】
2004192648.tif 000019
【図４】
2004192648.tif 000020
【図５】
2004192648.tif 000021
【図６】
2004192648.tif 000022
【図７】
2004192648.tif 000023