(57)【要約】【課題】フィルタドライバ用のファイルネームを管理する。【解決手段】フィルタマネージャは、要求されたファイルネームのタイプに対応するファイルネーム情報構造を指し示すポインタを、要求元のフィルタドライバに戻す。フィルタマネージャは、種々のフィルタドライバ間でシェアできる情報を含むファイルネーム情報構造のキャッシュを管理し、フィルタドライバのファイルネームケリーを譲渡する。フィルタマネージャのキャッシュ機能は、効率を上げるものであり、ファイルネームの所望の部分を検索するためファイルシステムフィルタドライバが必要とするファイルネームオペレーションの数を減少させて、ファイルシステム内のファイルネームケリーのオーバヘッドを減少させる。【選択図】　図１
2004038960.tif 000002
【特許請求の範囲】
【請求項１】
ファイルシステムフィルタドライバのためのファイルネームを管理する方法において、
指定されたフォーマットのファイルネームに対するファイルネーム要求を第１フィルタドライバから受け取るステップと、
前記ファイルネーム要求に対応するファイルネームを生成するため、ファイルネームプロバイダをコールするステップと、
生成されたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造をキャッシュするステップと、
前記生成されたファイルネーム情報構造を指し示すポインタを前記第１フィルタドライバに戻すステップと
を備えたことを特徴とする方法。
【請求項２】
請求項１において、前記ファイルネームを生成するため前記ファイルネームプロバイダをコールする前に、前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定するステップをさらに備えたことを特徴とする方法。
【請求項３】
請求項１において、前記第１フィルタドライバが前記生成されたファイルネーム情報構造を利用している間、当該ファイルネーム情報構造が維持されるようにするため、前記ポインタが前記第１フィルタドライバに戻されたとき、前記生成されたファイルネーム情報構造に関係付けされている参照カウントを更新するステップをさらに備えたことを特徴とする方法。
【請求項４】
請求項１において、前記生成されたファイル情報構造をキャッシュする前に前記ファイルネーム情報構造が有効か否かを判定されるようにするため、前記ポインタが前記第１フィルタドライバに戻されたとき、前記生成されたファイルネーム情報構造に関係付けされているタイムスタンプを更新するステップをさらに備えたことを特徴とする方法。
【請求項５】
請求項１において、前記ファイルネーム要求を受け取るステップは、前記第１フィルタドライバの識別子を指定するファイルネーム要求と、前記ファイルネームによって識別されたファイルのオープンインスタンスに対応するファイルオブジェクトと、前記ファイルネームのフォーマットとを受け取るステップをさらに備えたことを特徴とする方法。
【請求項６】
請求項５において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、及びショートのうちの少なくとも１つを備えたことを特徴とする方法。
【請求項７】
請求項１において、前記ファイルネームプロバイダをコールするステップは、第２のフィルタドライバが前記ファイルネームプロバイダとしてオペレートしているとき、アルティチュードの低い第２のフィルタドライバを、前記第１フィルタドライバからコールするステップをさらに備えたことを特徴とする方法。
【請求項８】
請求項１において、リネームプロシージャが進行中であるか否かを判定するステップと、
前記リネームプロシージャが前記ファイルネームの少なくとも一部分を変更するとき、ファイルネーム情報構造のキャッシュの適正な部分をパージするステップと
をさらに備えたことを特徴とする方法。
【請求項９】
請求項１において、前記生成されたファイルネーム情報構造は、ストリームレベル及びファイルオブジェクトレベルのうちの一方のレベルでキャッシュされることを特徴とする方法。
【請求項１０】
請求項１において、
リネームが進行中であるか否かを判定するステップと、
前記リネームが終了したタイムと、前記生成されたファイルネーム情報構造が作成されたタイムとを比較するステップと、
前記生成されたファイルネーム情報構造が作成されたタイムと比較した結果、前記リネームが終了したタイムの方が遅い場合に、前記ポインタを前記第１フィルタドライバに戻さないようにするステップと
をさらに備えたことを特徴とする方法。
【請求項１１】
請求項１において、ファイルネームトンネリングがいつ生じたかを判定してファイルネームトンネリングを補償するステップと、
ファイルネームトンネリングが生じたとき、前記生成されたファイルネーム情報構造をキャッシュしないようにするステップと
をさらに備えたことを特徴とする方法。
【請求項１２】
コンピュータ実行可能なコンポーネントを有するコンピュータ可読媒体において、
ファイルシステムのための第１フィルタドライバにより行なわれるファイルネーム要求を管理する第１コンポーネントを備え、
前記第１コンポーネントは、
指定されたフォーマットを有するファイルネームのための前記第１フィルタドライバから、ファイルネーム要求を受け取り、
前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定し、前記ファイルネーム情報構造が予めキャッシュされている場合に、前記ファイルネーム情報構造を指し示すポインタを前記フィルタドライバに戻し、
前記ファイルネーム情報構造が予めキャッシュされていない場合に、
前記ファイルネーム要求に対応するファイルネームを生成するため、ファイルネームプロバイダをコールし、
生成されたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造をキャッシュし、
前記生成されたファイルネーム情報構造を指し示すポインタを前記第１コンポーネントに戻す
ように構成したことを特徴とするコンピュータ可読媒体。
【請求項１３】
請求項１２において、前記第１コンポーネントは、前記第１フィルタドライバによるファイルネーム要求に加えて、前記ファイルシステムのための入力／出力要求を、前記第１コンポーネントが受け取って処理するようにするため、前記ファイルシステムと、オペレーティングシステムに関係付けされている外部アプリケーションとの間に、配置されたことを特徴とするコンピュータ可読媒体。
【請求項１４】
請求項１２において、前記第１コンポーネントは、ファイルネーム情報構造がキャッシュされるファイルネームキャッシュデータ構造を含み、
前記ファイルネームキャッシュデータ構造は、前記ファイルネーム情報構造に対応する前記ファイルネームのフォーマットに従って編成される
ことを特徴とするコンピュータ可読媒体。
【請求項１５】
請求項１２において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、又はショートのうちの少なくとも１つであることを特徴とするコンピュータ可読媒体。
【請求項１６】
データ構造でエンコードされたコンピュータ可読媒体において、
参照カウント及びタイムスタンプを含むヘッダと、
ボリューム上のファイルのファイルネームを指し示すポインタを含む第１データフィールドと
を備え、
前記参照カウントは、前記参照カウントが、予め定めた整数に到達するまで、前記データ構造が削除されないようにするのを支援し、
前記タイムスタンプは、特定の時点で前記データ構造の有効性を判定するのを支援し、
前記ポインタは、それぞれフィルタネームの予め定めたフラグメントを指し示す
ことを特徴とするコンピュータ可読媒体。
【請求項１７】
請求項１６において、前記ヘッダ及び第１データフィールドは、前記ファイルネームのフォーマットに従って配置されたツリーデータ構造内にストアされ、
前記フォーマットは、ノーマライズド、オープンド、又はショートのうちの少なくとも１つである
ことを特徴とするコンピュータ可読媒体。
【請求項１８】
請求項１７において、前記ツリーデータ構造は、
特定のノードが、前記ファイルネームに対応する前記データ構造を指し示すポインタを提供するようにするため、
前記ボリューム上の前記ファイルに関係付けされたファイルオブジェクトに対応する第１キーと、前記ファイルネームのプロバイダに対応する第２キーとに従ってアクセスされるノードを含む
ことを特徴とするコンピュータ可読媒体。
【請求項１９】
ファイルシステムフィルタドライバのためのファイルネームを管理するためのコンピュータ実行可能命令を有するコンピュータ可読媒体において、
前記命令は、
指定されたフォーマット内のファイルネームに対するファイルネーム要求を、前記第１フィルタドライバから受け取るステップと、
前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定し、前記ファイルネーム情報構造が予めキャッシュされている場合に、前記ファイルネーム情報構造を指し示すポインタを前記フィルタドライバに戻すステップと、
前記ファイルネーム情報構造が予めキャッシュされていない場合には、
前記ファイルネーム要求に対応するファイルネームを生成するため、ファイルネームプロバイダをコールするステップと、
生成されたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造をキャッシュし、
前記生成されたファイルネーム情報構造を指し示すポインタを、前記第１フィルタドライバに戻すステップと
を備えたことを特徴とするコンピュータ可読媒体。
【請求項２０】
請求項１９において、前記生成されたファイルネーム情報構造が前記第１フィルタドライバに使用される間維持されるようにするため、前記ポインタが前記第１フィルタドライバに戻されるとき、前記生成されたファイルネーム情報構造に関係付けされている参照カウントを更新するステップを備えたことを特徴とするコンピュータ可読媒体。
【請求項２１】
請求項１９において、前記生成されたファイル情報構造をキャッシュする前に、前記ファイルネーム情報構造が有効か否かを判定するようにするため、前記ポインタが前記第１フィルタドライバに戻されるとき、前記生成されたファイルネーム情報構造に関係付けされているタイムスタンプを更新するステップを備えたことを特徴とするコンピュータ可読媒体。
【請求項２２】
請求項１９において、前記ファイルネーム要求を受け取るステップは、前記第１フィルタドライバの識別子を指定するファイルネーム要求と、前記ファイルネームによって識別されたファイルのオープンインスタンスに対応するファイルオブジェクトと、前記ファイルネームのフォーマットとを受け取ることを特徴とするコンピュータ可読媒体。
【請求項２３】
請求項２２において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、及びショートのうちの少なくとも１つを含むことを特徴とするコンピュータ可読媒体。
【請求項２４】
請求項１９において、リネームプロシージャが進行中であるか否かを判定するステップと、
前記リネームプロシージャが前記ファイルネームのうちの少なくとも一部を変更する場合に、ファイルネーム情報構造のキャッシュの適正な部分をパージするステップとを備えたことを特徴とするコンピュータ可読媒体。
【請求項２５】
請求項１９において、前記生成されたファイルネーム情報構造は、ストリームレベル及びファイルオブジェクトレベルのうちの一方のレベルでキャッシュされることを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法に関する。
【背景技術】
【０００２】
ファイルシステムドライバ（ＦＳＤ）は、ファイルシステムフォーマットを管理する。ＦＳＤは、カーネルモードでラン（ｒｕｎ）するが、標準のカーネルモードドライバとは多くの点で異なっている。最も重要なのは、ＦＳＤ自体が、それぞれオペレーティングシステムによりファイルシステムドライバとして登録されることである。ファイルシステムドライバより上のレイヤーにあるフィルタドライバは、ファイルシステムフィルタドライバという。ファイルシステムフィルタドライバには、ファイルシステム要求をビュー（ｖｉｅｗ）し、その要求を、オプションで、修正するか処理する（ｃｏｍｐｌｅｔｅ）能力が含まれる。ファイルシステムフィルタドライバには、暗号化、ウィルス検出、及び他のオペレーションをパフォームするフィルタドライバを含めることができる。
【０００３】
一般に、ファイルシステムフィルタドライバをインプリメントするコードは、大部分が、ファイルネーム検索とフォーマットとで占められる。ファイルシステム（例えば、ＮＴＦＳ、ＦＡＴ等）によって、許容されるファイルネームのサイズを変えることができる。例えば、ＮＴＦＳは、ファイルネームパスにある各コンポーネントが２５５キャラクタに限定され、合計のファイルネームの長さが６５５３６キャラクタに限定されるように、ネームスペシフィケーション（ｎａｍｅｓｐｅｃｉｆｉｃａｔｉｏｎ）を設定する。ファイルネームには、Ｕｎｉｃｏｄｅキャラクタを含めることができ、同様に、複数のピリオドと、埋込みスペース（ｅｍｂｅｄｅｄｓｐａｃｅ）とを含めることができる。しかし、あるファイルシステムは、ファイルネームが８キャラクタ（非Ｕｎｉｃｏｄｅ）に限定され、ファイルネームの後に、ピリオドと、３キャラクタの拡張子とが来るようになっており、これは一般に「８．３」フォーマットと呼ばれている。そこで、元々これらのファイルシステムためにライト（ｗｒｉｔｅ）されたアプリケーションにおいても、８．３フォーマットか、又はこれと互換性のあるファイルネームを理解するできるようになっている。ＮＴＦＳのような他のファイルシステムにおいては、アプリケーションによりショートネーム（ｓｈｏｒｔｎａｍｅ）が要求されたとき、当該ファイルシステムは、ロングネーム（ｌｏｎｇｎａｍｅ）で作成されたファイルに代えて、８．３フォーマットのショートネームを生成する。ロングネームは、８．３フォーマットよりも長いファイルネームと、Ｕｎｉｃｏｄｅキャラクタを含むファイルネームと、複数のピリオドキャラクタ又は１つのビギニングピリオド（ｂｅｇｉｎｎｉｎｇｐｅｒｉｏｄ）を有するファイルネームと、埋込みスペースを有するファイルネームとに対応する。ショートネームは、ファイル用のフル機能（ｆｕｌｌｙｆｕｎｃｔｉｏｎａｌ）を有するエイリアス（ａｌｉａｓ）であり、ロングネームと同じディレクトリにストアされている。ロングネームもショートネームも、ファイルをオープンするか、リードするか、ライトするか、又はコピーするのに使用することができる。
【０００４】
ファイルネーム用のフォーマットは他にも存在し、ファイルシステムフィルタドライバは、これらフォーマットのうちのいずれかのフォーマットのファイルネームのケリーを開始することができる。ファイルネームは、Ｉ／Ｏオペレーション時にどのアクションを行うべきかをコントロールするため、ファイルシステムフィルタドライバにより使用されるのが一般的である。ユーザ又はアプリケーションは、ファイルネームを、多くの異なるフォーマットのうちの１つで、指定することができる。ファイルシステムフィルタドライバにおいては、当該ファイルネームがそのオペレーションに関係しているか否かを試験するため、当該ファイルネームを標準フォーマットにノーマライズ（ｎｏｒｍａｌｉｚｅ）することもある。ファイルシステムフィルタドライバは、一般に、ファイルネームをパース（ｐａｒｓｅ）してフラグメント（ｆｒａｇｍｅｎｔ）にする。例えば、ウィルスを検出できるファイルシステムフィルタドライバは、ファイルネームの拡張子のタイプ（例えば、．ｅｘｅ、．ｄｌｌ等）に最も関心を持ち、ファイルネームから拡張子をパースしようとする。現在では、複数のフィルタドライバが、それぞれ、自分に、１つのＦＳＤにアタッチ（ａｔｔａｃｈ）することができるが、各フィルタドライバが、当該ＦＳＳに対してファイルネームをケリーするから、リソースを消費（ｃｏｎｓｕｍｅ）する。各ファイルシステムフィルタドライバには、コードが含まれ、これらファイルシステムフィルタドライバは、ファイルネームを管理し操作するため、プロセスタイム（ｐｒｏｃｅｓｓｔｉｍｅ）をファイルネームの管理及び操作に当てる。
【考案の開示】
【課題を解決するための手段】
【０００５】
本発明によれば、ファイルシステムフィルタドライバ（以下「フィルタドライバ」という。）用のファイルネームオペレーションを処理し、償却する（ａｍｏｒｔｉｚｅ）ためのファイルシステムフィルタマネージャ（以下「フィルタマネージャ」という。）を含む。フィルタマネージャは、各フィルタドライバに共通のファイルネームの検索及びフォーマット化機能を提供する。さらにフィルタマネージャは、１つ以上のフィルタドライバでシェアできるネーム情報のキャッシュを提供する。キャッシュ、ファイルネーム検索、及びフォーマット化機能は、フィルタマネージャ内でのファイルネーム管理を統合することによって、ファイルシステム内でのファイルネーム管理の効率を上げるものである。
【０００６】
本発明は、ファイルシステム内のフィルタドライバ用のファイルネームを管理する。本発明は、フィルタドライバからのファイルネームケリーを処理するフィルタマネージャを含む。フィルタマネージャは、ドライバスタック内のフィルタドライバからのファイルネーム要求を受け取って処理する。フィルタマネージャは、前に生成されたファイルネームに関するファイルネーム情報構造のキャッシュを維持する。各ファイルネーム情報構造は、ファイルネームのフラグメントを指し示すポインタを含むポインタリストを備えている。フィルタマネージャは、第一に、フィルタドライバによるファイルネーム要求に対応するファイルネーム情報構造が前に生成されたか否かを判定するため、キャッシュを試験する。このようなファイルネーム情報構造が存在しない場合には、フィルタマネージャは、そのファイルネームのファイルネームプロバイダをコールする。ファイルネーム情報構造が作成されていた場合には、フィルタマネージャは、ファイルネーム情報構造に関係付けされている参照カウント及びタイムスタンプを更新する。参照カウントは、ファイルネーム情報構造が少なくとも１つのフィルタドライバによって使用されている限り、ファイルネーム情報構造が有効であることを保証するものである。タイムスタンプは、ファイルがリネーム（ｒｅｎａｍｅ）されるとき、又はその後のオペレーションがファイルネームに影響を与えるとき、ファイルネーム情報構造が、ファイル用の現在のファイルネームを反映することを保証するものである。ついで、フィルタマネージャは、対応するファイルネーム情報構造を指し示すポインタを、要求側フィルタドライバに戻す。
【発明を実施するための最良の形態】
【０００７】
簡潔に言えば、本発明は、ファイルシステムにおいて、フィルタドライバ用のファイルネームを管理する方法及びシステムに関する。本発明には、フィルタドライバからのファイルネームケリーをハンドル（ｈａｎｄｌｅ）するフィルタマネージャが含まれる。フィルタマネージャは、要求されたファイルネームのタイプに対応するファイルネーム情報構造を指し示すポインタを、要求側フィルタドライバに戻す。このフィルタマネージャは、次のようなファイルネーム情報構造のキャッシュも管理し、フィルタドライバに対して行うファイルネームケリーを償却する（ａｍｏｒｔｉｚｅ）。このファイルネーム情報構造には、種々のフィルタドライバでシェア（ｓｈａｒｅ）できる情報が含まれる。このフィルタマネージャにキャッシュ機能があるので、ファイルシステムフィルタドライバがファイルネームの所望の部分を取り出すのに要求されるファイルネームオペレーションの数が減少し、これにより、効率が良くなり、ファイルシステム内でのファイルネームケリーのオーバヘッドが減少する。
【０００８】
本明細書及び特許請求の範囲においては、当該コンテキストが明確にそうでないと述べない限り、次の用語は、本明細書に明示的に関係付けをした意味を有するものとする。
【０００９】
「ＦＩＳ（ＦｉｌｅＩｎｆｏｒｍａｔｉｏｎＳｔｒｕｃｔｕｒｅ）」とは、フィルタマネージャに関係付けをしたデータ構造であって、少なくとも一実施形態においては、ボリューム（ｖｏｌｕｍｅ）にストアされた特定のファイルネームのネームフラグメント（ｎａｍｅｆｒａｇｍｅｎｔ）を指し示すポインタをストアするデータ構造をいう。「ネームフラグメント」とは、ファイルネームの一部をいう。例えば、ファイルネームには、拡張子（例えば、．ｔｘｔ、．ｄｌｌ、．ｄｏｃなど）が含まれるのが典型的である。この拡張子は、ネームフラグメントの１つのタイプを表す。
【００１０】
「アルティチュード（ａｌｔｉｔｕｄｅ）」とは、特定のフィルタドライバが、アプリケーションと、ボリュームを管理するファイルシステムとの間で送信されるＩＲＰ（Ｉｎｐｕｔ／ＯｕｔｐｕｔＲｅｑｕｅｓｔＰａｃｋｅｔ）に応答する順番（ｏｒｄｅｒ）をいう。当該ファイルシステムにおいて、他のフィルタドライバよりアルティチュードの高いフィルタドライバは、「ｆｕｒｔｈｅｒａｗａｙ」といわれ、当該ＩＲＰがアプリケーションから送信されるとき、ＩＲＰに関係付けされたオペレーションを、これら他のフィルタドライバより早くハンドルする。これに対して、当該ＩＲＰがファイルシステムから送信されるとき、ＩＲＰに関係付けされたオペレーションを、他のフィルタドライバより遅く処理する場合、当該フィルタドライバのアルティチュードは低い。これらＩＲＰとは、多くの場合、ＩＯサブシステムにおいて使用されるデータ構造をいうが、これらにはＮＴＦＳのようなファイルシステムが含まれる。しかしながら、たとえＩＲＰのみを参照できるとしても、当然、本発明に係るフィルタマネージャは、当該ＩＲＰを、別のデータ構造、例えば、所定のオペレーションをフィルタに提示するためのＣａｌｌｂａｃｋＤａｔａ構造に、変換することができる。
【００１１】
「ファイルネームプロバイダ」とは、ファイルシステムか、又はファイルに代替のファイルネームを提供するために登録された特定のフィルタドライバか、のいずれかをいう。
【００１２】
オペレーティング環境の例
図１を説明する。本発明をインプリメントしたシステムの例には、コンピューティング装置１００のようなコンピューティング装置が含まれる。非常に基本的な構成においては、コンピューティング装置１００には、少なくとも１つのプロセシングユニット１０２と、システムメモリ１０４とが含まれるのが典型的である。正確な構成と、コンピューティング装置のタイプとに応じて、システムメモリ１０４は、（ＲＡＭのような）揮発性メモリか、（ＲＯＭ、フラッシュメモリのような）不揮発性メモリか、又はこれらメモリを組み合わせたものとすることができる。システムメモリ１０４には、オペレーティングシステム１０５と、１つ以上のプログラムモジュール１０６と、プログラムデータ１０７とが含まれるのが典型的である。さらに、オペレーティングシステム１０５には、本発明に係るフィルタマネージャ１２０を含めることができる。この基本的な構成は、図１において、破線１０８内のコンポーネントで図示してある。
【００１３】
コンピューティング装置１００は、フィーチャ（ｆｅａｔｕｒｅ）又は機能を追加することができる。例えば、コンピューティング装置１００には、追加の（リムーバブル及び／又はノンリムーバブル）データストレージ装置、例えば、磁気ディスク、光ディスク、又はテープを含めることもできる。このような追加のストレージ装置としては、図１において、リムーバブルストレージ１０９と、ノンリムーバブルストレージ１１０が図示してある。コンピュータ記憶媒体には、揮発性及び不揮発性、リムーバブル及びノンリムーバブルの媒体であって、情報を記憶するための方法又は技術、例えば、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータを、インプリメントした媒体を含めることができる。システムメモリ１０４、リムーバブルストレージ１０９、及びノンリムーバブルストレージ１１０は、全て、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリその他のメモリ技術か、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌｖｅｒｓａｔｉｌｅｄｉｓｋ）その他の光記憶装置か、磁気カセット、磁気テープ、磁気ディスク記憶装置その他の磁気記憶装置か、あるいは、所望の情報をストアするために使用可能な媒体であってコンピューティング装置１００がアクセス可能な他の媒体が含まれるが、これらに限定されるものではない。このようなコンピュータ記憶媒体は、コンピューティング装置１００の一部とすることができる。コンピューティング装置１００は、入力装置１１２、例えばキーボード、マウス、ペン、音声入力装置、タッチ入力装置を有することができる。出力装置１１４、例えばディスプレイ、スピーカ、プリンタも含めることができる。これらの装置は、当分野で周知のものであるから、ここでは詳細に述べない。
【００１４】
コンピューティング装置１００は、通信コネクション１１６も含むことができ、これにより、他のコンピューティング装置１１８と、例えばネットワークを介して、通信することができる。通信コネクション１１６は、通信媒体の一例である。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又は変調データ信号、例えば、搬送波その他のトランスポートメカニズム上の他のデータにより具現化できるのが典型的であり、この通信媒体には、情報配信媒体（ｉｎｆｏｒｍａｔｉｏｎｄｅｌｉｖｅｒｙｍｅｄｉａ）が含まれる。「変調データ信号」とは、情報をエンコードして信号中に入れて設定（ｓｅｔ）するか変化させた１つ以上の特性を有する信号をいう。例えば、通信媒体には、ワイヤード（ｗｉｒｅｄ）媒体、例えば、ワイヤード（ｗｉｒｅｄ）ネットワーク又はダイレクトワイヤード接続と、ワイヤレス（ｗｉｒｅｌｅｓｓ）媒体、例えば、音波、ＲＦ、赤外線等が含まれるが、これらに限定されるものではない。本明細書において使用されるコンピュータ可読媒体という用語には、記憶媒体と、通信媒体とが含まれる。
【００１５】
フィルタドライバ構造とファイルシステム
図２は、本発明を実施するための環境例を示すブロック図である。図２に示す環境は、ファイルシステムのためのＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）サブシステム環境２００であって、このＩＯサブシステム環境２００には、本発明に係るフィルタマネージャ１２０が含まれる。
【００１６】
ファイルシステム環境２００には、ユーザモードでオペレートするアプリケーション２０２と、カーネルモードでオペレートするＮＴＦＳファイルシステム２２０とが含まれる。ここにおいては、ＮＴＦＳのコンテキストで記載するが、当然、本発明は、他の多くのファイルシステム、例えばＦＡＴ、ＦＡＴ３２、ＥＸＴ２、ＨＰＦＳ等に対しても等しく適用可能である。
【００１７】
ＮＴＦＳ２２０とアプリケーション２０２との間に、カーネルモードでオペレートするフィルタドライバ構造２１０がある。フィルタドライバ構造２１０には、フィルタマネージャ１２０が含まれるとともに、複数のフィルタドライバ（例えば、２１２Ａ〜Ｃ）からなるフィルタドライバスタックが含まれる。ＮＴＦＳ２２０は、ボリューム２３０にストアされたファイルシステム構造を管理するため、システムメモリ１０４内において、複数のデータ構造（例えば、２４０）を維持している。データ構造２４０については、以下に、図３を参照して詳細に述べる。ボリューム２３０には、ファイルレコードのアレイ（ａｒｒａｙ）を提供するＭＦＴ（ｍａｓｔｅｒｆｉｌｅｔａｂｌｅ）２３２が含まれるが、このファイルレコードのアレイには、ボリューム２３０が有する各ファイルに対して１つのレコードが含まれ、レコードとしてはＭＦＴ２３２に対するレコードもある。例えば、ＭＦＴ２３２には、ファイルネーム属性２３４のレコードを含めることができ、追加のファイルネーム属性２３４を含む他のファイルレコードを指し示すポインタを含めることができる。
【００１８】
ＩＯサブシステム環境２００においては、フィルタドライバ２１２Ａ〜Ｃにより、ＮＴＦＳファイルシステム２２０に機能が追加される。前に述べたシステムにおいては、フィルタドライバ２１２Ａ〜Ｃは、カーネルモードでオペレートしているＮＴＦＳ２２０と、ユーザモードでオペレートしているアプリケーション２０２との間で送信さるＩＲＰをインタセプト（ｉｎｔｅｒｃｅｐｔ）する。例えば、アプリケーションは、ファイルを作成するためのファンクション（ｆｕｎｃｔｉｏｎ）（例えば、ＣｒｅａｔｅＦｉｌｅ）をコールしてファイルにアクセスする。これに応答して、指定されたタイプのＩＲＰが生成される。この生成されたＩＲＰにより、オープンされているファイルのネームをストアするファイルオブジェクトが作成され、ついで、このＩＲＰがフィルタ構造２１０に渡される。フィルタドライバ２１２Ａ〜Ｃは、それぞれ、指定された機能をインプリメントするため、このＩＲＰが参照するファイルネームをルックアップ（ｌｏｏｋｕｐ）することができる。そして、ハンドルが、コーリングチェーン（ｃａｌｌｉｎｇｃｈａｉｎ）を介して戻され、戻りパラメータ（ｒｅｔｕｒｎｐａｒａｍｅｔｅｒ）として、アプリケーション２０２に到達することになる。
【００１９】
フィルタドライバの機能としては、フィルタドライバがＩＲＰを受け取ったとき、ＩＲＰに関係付けされているファイルのファイルネームを知ったか否かに依存する機能がある。例えば、ウィルス検出用のフィルタドライバは、ファイルネーム中に「．ｅｘｅ」又は「．ｄｌｌ」の拡張子の付いたファイルに集中することができる。あるいはまた、暗号化向けのフィルタドライバは、特定パスのファイルの暗号化に集中することができる。このＩＲＰには、このＩＲＰに関係付けされているファイルのフル（ｆｕｌｌ）ファイルネームが含まれていなくてもよい。例えば、アプリケーション２０２からのファンクションコールの、リード、ライト、又は作成においては、ファイルネームではないファイルＩＤを指定することができる。このファイルＩＤとは、ボリューム２３０が有するファイルを一意に識別する数字である。ＣＲＥＡＴＥ又はＯＰＥＮオペレーションのために、ユーザがファイルを識別するのに使用するファイルネーム又はＩＤは、当該ファイルにとって、ｐｒｅ―ＣＲＥＡＴＥ期間の間、有効である。ＣＲＥＡＴＥ又はＯＰＥＮオペレーションの後、ファイルオブジェクトには、ＮＴＦＳ２２０が、ファイルのファイルネームを使用せずに、どのファイルが参照されているかを識別できるデータ構造が、含まれる。したがって、仮にフィルタドライバ（例えば、２１２Ａ〜Ｃ）が、ｐｒｅ―ＣＲＥＡＴＥ期間の後に、ファイルネームが必要な場合には、ＮＴＦＳ２２０にファイルネームをケリーする。フィルタドライバ２１２Ａ〜Ｃは、オペレーションを完了させるため、ＮＴＦＳ２２０へのファイルネームのケリーを開始することを要求することができる。
【００２０】
本発明においては、フィルタドライバスタック（すなわち、フィルタドライバ２１２Ａ〜Ｃ）によりシリアルに渡されるＩＲＰに代えて、当該ＩＲＰが、フィルタマネージャ１２０に直接渡される。ついで、フィルタマネージャ１２０は、各フィルタドライバ２１２Ａ〜ＣにＩＲＰを通知するから、当該ＩＲＰに関係する機能を含むフィルタドライバは、フィルタマネージャ１２０と（例えば、コールバックにより）、インタラクトすることができる。フィルタドライバ２１２Ａ〜Ｃがフィルタマネージャ１２０とインタラクトできる１つの方法は、指定されたオペレーションを完了するため、フィルタマネージャ１２０に対してファイルネームをケリーしてインタラクトする方法である。フィルタマネージャ１２０は、フィルタドライバ２１２Ａ〜Ｃによるファイルネームの要求を管理する。
【００２１】
フィルタマネージャ１２０により、３つのフォーマット、すなわち、ノーマライズド（Ｎｏｒｍａｌｉｚｅｄ）、ショート（Ｓｈｏｒｔ）、又はオープンド（Ｏｐｅｎｅｄ）のうちの１つのフォーマットで、ファイルネームをケリーすることができる。ノーマライズドファイルネームは、ショートネームが拡張されたものであり（すなわち、ノーマライズドファイルネームはロングネームである）、ディレクトリのルートからのファイルのフルパスを有するから、マウントポイントが解決（ｒｅｓｏｌｖｅ）される（図１０に関する説明を参照されたい）。オープンドファイルネームには、ファイルをオープンするために使用されたフォーマットのファイルネームが含まれる（例えば、ショートネーム又はロングネームのいずれかを含むことができる）。ショートファイルネームには、ファイルのフルパスの最終コンポーネントであって、８．３フォーマット（例えば、「ｆｉｌｅｎａｍｅ．ｅｘｔ」）のファイルネームのみが含まれる。
【００２２】
フィルタマネージャ１２０は、プロセス中の特定時間においては、あるファイルネームフォーマットをケリーすることができない。例えば、アプリケーション２０２によってファイル作成オペレーション（すなわち、ファイルオープンオペレーション）が開始されたときは、オペレーションがＮＴＦＳ２２０に達するまでは、新しく作成されたファイルのファイルネームが有効であるか否かを判定することが、恐らく、不可能になる。この期間の間は、フィルタマネージャ１２０はショートファイルネームフォーマットで、ファイルネームをケリーすることはできない。これは、ショートファイルネームフォーマットの有効性（ｖａｌｉｄｉｔｙ）が疑わしいからである。
【００２３】
図３は、本発明に係るＮＴＦＳファイルシステムによって維持されるデータ構造２４０の例を示す。データ構造２４０には、ファイルオブジェクト３１０及び３１２と、ストリームコントロールブロック（ＳＣＢ）３２０と、ファイルコントロールブロック（ＦＣＢ）３３０とが含まれる。
【００２４】
ファイルは、１つ以上のデータストリームにより構成され、そのうちの１次データストリームをネーム無し（ｕｎｎａｍｅｄ）とすることができる。このファイルシステムは、ＳＣＢ（例えば、３２２及び３２４）を使用して、ファイルの各データストリームを一意に識別する。例えば、ＳＣＢ３２２は、ファイルオブジェクトのうちの１つのファイルオブジェクト（例えば、図３に３１０で示す）に対しては、１次のネーム無しストリームであり、ＳＣＢ３２４は、このファイルオブジェクトに対しては２次のネーム付きストリームである。ファイルオブジェクト（３１０、３１２）は、ファイルの特定データストリーム（ネーム付き又はネーム無し）のオープンに対応する。このファイルシステムは、ファイルオブジェクト（３１０、３１２）から、ＭＦＴ２３２によって提示されているボリュームが有するファイルのロケーションを指し示すポインタを幾つか作成する。ファイルオブジェクト３１０及び３１２は、それぞれオープンファイルの単一のインスタンスを表すものであるが、コール側アプリケーションがリード又はライトを試みているファイルに対応するＳＣＢ（ｓｔｒｅａｍｃｏｎｔｒｏｌｂｌｏｃｋ）３２０を指し示している。特定のファイルに対するＳＣＢは、共通のファイルコントロールブロック（例えば、３３０）を指し示している。ＦＣＢ３３０には、ＭＦＴ２３２のファイルのレコードを指し示すポインタが含まれる。
【００２５】
図４は、ファィルオブジェクトと、本発明に係るフィルタマネージャデータ構造との間の関係を示す。図３に関して述べたように、ファイルオブジェクト３２０はファイルのオープンインスタンスを表す。あるタイプのドライバ、例えばフィルタドライバは、ファイルオブジェクト３２０内のフィールドのうちの幾つかを利用することができる。本発明は、ファイルオブジェクト３２０内のフィールドを、ポインタ用に使用している。ポインタ（ＰｖｏｉｄＦｓＣｏｎｔｅｘｔ）は、ＦｓＣｏｎｔｅｘｔ共通ヘッダ４１０というデータ構造であって、ロックと、パーストリームコンテキスト（ｐｅｒｓｔｒｅａｍｃｏｎｔｅｘｔ）のリンクされたリストとが含まれるデータ構造を指し示している。このＦｓＣｏｎｔｅｘｔ共通ヘッダ４１０は、ファイルシステムが「パーストリームコンテキスト」機能をサポートするか否かを指定する。「パーストリームコンテキスト」とは、ファイルシステム（ＮＴＦＳファイルシステムに存在するようなファイルシステム）により、他のドライバが幾つかの情報をこのストリームに関係付けすることができるか否かをいう。ＦｓＣｏｎｔｅｘｔ共通ヘッダ４１０は、フィルタドライバがポピュレート（ｐｏｐｕｌａｔｅ）できるパーストリームコンテキストのリンクされたリストに、指定された機能のための情報を提供する。ＦｓＣｏｎｔｅｘｔ共通ヘッダ４１０は、ファイルシステムに応じて、ファイルコントロールブロック（ＦＣＢ）又はストリームコントロールブロック（ＳＣＢ）のいずれかとすることができる。本発明において、ＮＴＦＳファイルシステムに関しては、ＦｓＣｏｎｔｅｘｔ共通ヘッダ４１０は、パーストリームコンテキストのリンクされたリストを含むＳＣＢであって、コンテキストをファイルオブジェクト（例えば、３２０）に提供するためのものである。パーストリームコンテキスト４１２には、それぞれ、２つのキー（Ｋｅｙ１、Ｋｅｙ２）が含まれるとともに、フィルタマネージャによって維持されるフィルタマネージャデータ構造４２０を指し示すポインタ（ｐＶｏｉｄＦＭＤＳ）が含まれる（図２を参照）。フィルタマネージャデータ構造４２０は、フィルタドライバからの要求に応答して作成された各ファイルネームのためのＦＩＳ（ｆｉｌｅｎａｍｅｉｎｆｏｒｍａｔｉｏｎｓｔｒｕｃｔｕｒｅ）（図５を参照）をストアするためのキャッシュである。各フィルタマネージャデータ構造４２０は、さらに、各ＦＩＳに関係付けされたファイルネーム（例えばノーマライズドネーム、オープンドネーム、及びショートネーム）のフォーマットに従って、ネームキャッシュデータ構造４２２Ａ〜Ｃに編成される。
【００２６】
図５は、本発明に係るフィルタマネージャに関係付けされたデータ構造の例を示す。図４に示した各ネームキャッシュデータ構造４２２Ａ〜Ｃには、ツリー構造が含まれる。一実施形態においては、ツリー構造はスプレイ（ｓｐｌａｙ）ツリー構造である。スプレイツリーは、データベースにファイルを配置したり、データベースからファイルを突き止めたりすることに関連して共通に使用される。
【００２７】
本発明においては、当該ツリー構造のノード５１０は、特定のＦＩＳ５２０を指し示すことができる。ノード５１０は、２つのキー（Ｋｅｙ１、Ｋｅｙ２）でインデックス付けされており、ノード５１０には、ファイルネームに対応する適正なＦＩＳを指し示すポインタ（ｐＶｏｉｄＦＩＳ）が含まれる。図８に関連して説明するが、本発明においては、Ｋｅｙ１は要求されたファイルネームのファイルオブジェクトに対応し、Ｋｅｙ２はファイルネームのファイルネームプロバイダに対応する。
【００２８】
ＦＩＳ５２０には、プライベートヘッダ５２２と、ファイルネームポインタリスト５２４とが含まれる。特定ファイルネーム、すなわちノーマライズド、オープンド、又はショートに対して、異なるＦＩＳ５２０が可能である。言い換えれば、特定ファイル用のノーマライズドファイルネームと、これと同一のファイル用のショートファイルネームが、それぞれ異なるＦＩＳ５２０で表される。
【００２９】
プライベートヘッダ５２２には、参照カウント、タイムスタンプ、その他のデータに関するデータが含まれる。この参照カウントは、ＦＩＳ５２０が、フィルタドライバによって参照される限り、メモリに維持されることを保証する。このタイムスタンプは、ファイルがリネームされるか、又はリネーム後のオペレーションがファイルネームに影響を及ぼすとき、ＦＩＳ５２０が当該ファイルに対して現在のファイルネームを反映させる、ことを保証する。このタイムスタンプについては、図１０を参照して詳細に説明する。
【００３０】
ファイルネームポインタリスト５２４には、単一のメモリバッファにある同一のファイルネームのうちの指定された複数のフラグメントをそれぞれ指し示すポインタが含まれる。各フラグメントは、当該ファイルネームの一部を構成するＵｎｉｃｏｄｅストリングに対応する（図６を参照）。これらポインタは、ファイルネームを備えたキャラクタのアレイを示すインデックスとしてオペレートする。当該ファイルネームがフィルタマネージャによってパースされるから、当該ファイルネームのフラグメントを試験することを望むフィルタドライバは、当該ファイルネームを個々にパースする必要はない。
【００３１】
図６は、本発明によりラベル付けされたフラグメントを有するファイルネームの例を示す。このインプリメンテーションにおいては、ファイルネーム６００には、要求があれば提供することができるフィルタマネージャ（図２を参照）によって認識された６つのフラグメント（６１０、６２０、６３０、６４０、６５０、６６０）が含まれる。各フラグメントは、図５のファイルネームポインタリスト５２４にリストされているポインタのうちの１つによって、指し示されている。これらフラグメントには、ボリューム６１０、シェア（Ｓｈａｒｅ）６２０、親ディレクトリ６３０、最終コンポーネント６４０、拡張子６５０、及びストリーム６６０が含まれる。
【００３２】
ボリューム６１０とは、当該ファイルネームのうち、当該ファイルをストアする論理ボリュームを記述した部分をいう。ネットワークからのファイルにおいて、ボリューム６１０とは、当該ファイルネームのうち、リモートファイルにアクセスするのに使用されるネットワークプロバイダを記述する部分をいう（例えば、＼Ｄｅｖｉｃｅ＼ＬａｎｍａｎＲｅｄ＼）。
【００３３】
シェア６２０は、ローカルファイル用のＮＵＬＬストリングである。ただし、リモートファイルにおいて、シェア６２０とは、当該ファイルネームのうち、当該ファイルネームをネットワークプロバイダのネームスペースにストアするパスを記述する部分をいう。
【００３４】
親ディレクトリ６３０とは、最終コンポーネントを除去して得られるファイルネームのうちのフルパスを記述した部分をいう。
【００３５】
ファイルネームにおいて各コンポーネントは、「／」又は「＼」で区切られているが、最終コンポーネント６４０とは、ファイルネームストリングの末端にあるコンポーネントであってストリーム６６０を含むものをいう。
【００３６】
拡張子６５０とは、当該ファィルネームのうち、最後の「．」から任意のストリームまでの部分をいう。
【００３７】
ストリーム６６０とは、当該ファイルネームのうち、最終コンポーネントにある最初の「：」以降の部分をいう。
【００３８】
一実施形態において、あるフラグメントにあっては、その特定フラグメントを取得するとオーバヘッドコストが高くなるので、あるネームタイプ（例えば、ショートネーム）に従ってオープンされたファイルには利用できない。
【００３９】
フォーマット化、パース、及びキャッシングのためのプロセス
図７は、本発明に従ってパフォームされるファイルネームケリープロセスを示す流れ図である。このプロセスは、開始ブロック７０１から開始され、開始ブロック７０１において、図２のフィルタマネージャ１２０によってＩＲＰが受け取られ、このＩＲＰが、フィルタドライバ２１２Ａ〜Ｃのうちの１つに通知される。プロセス７００は、ブロック７０２に進む。
【００４０】
ブロック７０２にて、フィルタマネージャ１２０は、通知を受けたフィルタドライバから、特定ファイルネームの要求を受け取る。一実施形態においては、このファイルネーム要求は、フィルタマネージャ１２０が受け取ったＩＲＰに関係して行う。他の実施形態においては、このフィルタドライバが、このＩＲＰに無関係なオペレーションの一部として、ネーム要求を開始することができる。ファイルネーム要求がフィルタマネージャによって受け取られると、このフィルタマネージャはファイルネームを検索する。ファイルネーム要求処理プロセスの例については、図８を参照して説明する際に、詳細に説明する。本処理は、判定ブロック７０３に進む。
【００４１】
判定ブロック７０３において、当該ファイルネームに対応するＦＩＳが、このフィルタマネージャに対応するデータ構造（図４及び５を参照）内に前もってキャッシュされているか否かを判定する。仮にファイルネーム要求に対応するＦＩＳが前もってキャッシュされている場合には、本処理はブロック７０６にジャンプする。他方、仮にファイルネーム要求に対応するＦＩＳが以前にキャッシュされていない場合には、本処理はブロック７０４に進む。
【００４２】
ブロック７０４において、このフィルタマネージャは、ファイルネームのために、ファイルネームプロバイダをコールする。特定フィルタドライバのためのファイルネームプロバイダは、ボリュームにある同一の物理ファイルと異ならせることができる。ファイルネームプロバイダとしてオペレートするフィルタドライバは、当該ファイルネームを、アルティチュードの高いフィルタドライバに提供するが、通常、アルティチュードの低いフィルタドライバには提供しない。例えば、第１フィルタドライバのアルティチュードを、ファイルネームプロバイダとしてオペレートしている第２フィルタドライバよりも高くすることができる。第１フィルタドライバのためのファイルネームプロバイダは、第２フィルタドライバとなる。しかし、仮に第３フィルタドライバのアルティチュードが第２フィルタドライバよりも低い場合には、第２フィルタドライバは、第３フィルタドライバのためのファイルネームプロバイダとならない。当該ファイルネームを提供するファイルネームプロバイダをコールするプロセスの例については、図９を参照して説明する際に、詳細に説明する。本処理はブロック７０５に進む。
【００４３】
ブロック７０５において、ファイルネームプロバイダによって生成されたファイルネームためのＦＩＳが、フィルタマネージャによって提供されるデータ構造内にキャッシュされ、要求元のフィルタドライバにされる。フィルタマネージャ用のキャッシュのハンドリング（ｈａｎｄｌｉｎｇ）は、ファイルネームに現在適用されているプロセスと、ファイルネームのタイプその他の要素とに依存する。ＦＩＳを指し示すポインタは、フィルタマネージャによって、ファイルネーム要求を開始したフィルタドライバに戻される。ポインタは、フィルタドライバがＦＩＳのファイルネームポインタリストにアクセスすることによって、ネームフラグメントにアクセスできるようにするものである。ＦＩＳをキャッシュしてこれを要求元のフィルタドライバに戻すための例示的プロセスについては、図１０を参照して説明する際に、詳細に説明する。本処理はブロック７０６に進む。
【００４４】
ブロック７０６において、フィルタドライバが、現在、ＦＩＳを使用中であることを反映させるため、各ＦＩＳに関係付けされている参照カウントが更新（又はインクリメント）される。一実施形態においては、図５に示したように、参照カウントが、各ＦＩＳのプライベートヘッダに含められる。このＦＩＳに関係付けされているメモリは、参照カウントがゼロを超えていれば、有効である。任意のフィルタドライバが、このＦＩＳへの参照を獲得すると、この参照カウントがインクリメントされる。各フィルタドライバが、このＦＩＳへの参照を解放するとき、ネット（ｎｅｔ）カウントがデクリメントされる。このネットカウントがゼロになると、このＦＩＳが削除され、当該メモリが消去される。参照カウントは、特定のＦＩＳと、このＦＩＳに関係付けされているファイルネームとを含むメモリが、少なくとも必要な限度において有効である、ことを保証する。本処理はブロック７０７に進み、ブロック７０７において本処理が終了する。
【００４５】
一実施形態においては、プロセス７００は、ＣＲＥＡＴＥオペレーションに対しては、異なるオペレートをする。ＣＲＥＡＴＥオペレーションにおいては、当該ファイルシステムによって当該ファイルがまだオープンされていないので、当該ファイルのＳＣＢにリンクされたキャッシュデータ構造（例えば、ＦＩＳ）は、まだ生成されていない。フィルタドライバによってｐｒｅ―ＣＲＥＡＴＥ期間において要求されたファイルネームにあって、このファイルネームは、このファイルオブジェクトに関係付けされているオペレーションデータ構造（例えば、ＩＲＰ＿ＣＴＲＬ）キャッシュを試験することにより生成される。仮にオペレーションデータ構造キャッシュからファイルネームが生成できない場合には、ファイルネームプロバイダに対してこれらを生成するように要求される（図８を参照）が、ファイルネームは、ｐｏｓｔ―ＣＲＥＡＴＥ期間に達するまで、オペレーションデータ構造キャッシュにキャッシュされる。ｐｏｓｔ―ＣＲＥＡＴＥにおいて、仮にＣＲＥＡＴＥオペレーションが正しく完了した場合には、キャッシュデータ構造が生成される。仮にこのファイルネームが有効であり（図１０を参照）、トンネリング（ｔｕｎｎｅｌｉｎｇ）が発生していない（図１２を参照）場合には、ファイルネームがキャッシュされる。
【００４６】
図８は、本発明に従ってパフォームされるファイルネーム要求処理プロセスの例を示す流れ図である。図７のプロセス７００がブロック７０２に進むと、本処理がブロック８０１から開始される。本処理はブロック８０２に進む。
【００４７】
ブロック８０２において、このフィルタマネージャは、当該ファイルネームに関係付けされているファイルオブジェクトと、ファイルネームに対して要求されたフォーマット（例えば、ノーマライズド、オープンド、又はショート）とが含まれるファイルネームに対する要求を、フィルタドライバから受け取る。本処理はブロック８０３に進む。
【００４８】
ブロック８０３において、このフィルタマネージャは、ファイルネーム要求を行ったフィルタドライバから、ファイルネームプロバイダを判定する。前述したように、第１フィルタドライバは、アルティチュードが、ファイルネームプロバイダとしてオペレートしている第２フィルタドライバよりも高いが、この第２フィルタドライバを、そのファイルネームケリーのためのファイルネームプロバイダとして利用する。ドライバスタック内におけるフィルタドライバの順番は、このフィルタマネージャによって予め決定される。加えて、ファイルネームプロバイダとしてオペレートすることを望むフィルタドライバは、フィルタマネージャとともに、予め登録される。仮に要求元のフィルタドライバのアルティチュードが、指定されたファイルネームプロバイダよりも高い場合には、そのインスタンスのファイルネームプロバイダは、そのアルティチュードが、要求元フィルタドライバに最も近いが、要求元フィルタドライバよりも低いファイルネームプロバイダである。仮に要求元フィルタドライバが、他に、アルティチュードの低いファイルネームプロバイダとしてオペレートしているフィルタドライバを有していない場合には、このファイルシステムは要求元フィルタドライバのためのファイルネームプロバイダとしてオペレートする。一度要求元フィルタドライバのためのファイルネームプロバイダが決定されると、本処理はブロック８０４に進む。
【００４９】
ブロック８０４において、このフィルタマネージャによって提供されたデータ構造内に既にキャッシュさせることができるファイルネーム要求に対応するＦＩＳをサーチすることができる。図４に関連して既に述べたが、このデータ構造は、要求されたファイルネームフォーマット（例えば、ノーマライズド、オープンド、又はショート）に従って編成される。要求されたファイルネームフォーマットに対応するデータ構造は、２つのキー（Ｋｅｙ１、Ｋｅｙ２）（図５を参照）に従ってサーチされる。第１キーは、当該ファイルの特定のオープンインスタンスに関係付けされているファイルオブジェクトである。このファイルオブジェクトは、ＦＩＳが、同一のストリームレベル又はファイルオブジェクトレベルで、キャッシュされるか否かを指定するのを、支援する。これについては図１０を参照して詳細に述べる。第２キーは、ブロック８０３で識別されたファイルネームプロバイダである。仮にＦＩＳが予めストアされている場合には、２つのキー（Ｋｅｙ１、Ｋｅｙ２）に従って、フィルタドライバデータ構造をサーチして、現行のＦＩＳを突き止める。本処理はブロック８０５に進み、ついで図７のプロセス７００に戻り、ブロック７０４に進む。
【００５０】
図９は、本発明にしたがってパフォームされるファイルネーム生成プロセスの例を示す流れ図である。プロセス９００は、図７のプロセス７００がブロック７０４に進むと、ブロック９０１から開始される。本処理は判定ブロック９０２に進む。
【００５１】
判定ブロック９０２において、アルティチュードの低いフィルタドライバがファイルネームプロバイダとしてオペレートしているか否かを判定する。オペレートしていない場合には、このファイルシステムによってファイルネームが提供され、本処理はブロック９０６に進む。しかし、仮にアルティチュードの低いフィルタドライバがフィルタドライバとしてオペレートしている場合には、本処理はブロック９０３に進む。
【００５２】
ブロック９０３において、このファイルネームプロバイダからファイルネームを検索するため、ネームコールバックが利用される。使用されるコールバックのタイプは、デスティネーションファイルネームが要求元フィルタドライバによって要求されたか否かに依存する。このファイルネームプロバイダは、２つのコールバックを登録する。これら２つのコールバックのうちの一方のコールバック、すなわちＣｒｅａｔｅＤｅｓｔｉｎａｔｉｏｎＮａｍｅＣａｌｌｂａｃｋは、ファイルネームプロバイダよりも高いフィルタドライバによって、デスティネーションネームが要求されたとき、コールされる。その他方のコールバック、すなわちＣｒｅａｔｅＦｉｌｅＮａｍｅＣａｌｌｂａｃｋは、ファイルネームプロバイダよりも高い第２フィルタによって、ファイルネーム（デスティネーションファイルネームにおいてはない）が要求されたとき、第１フィルタドライバをコールする。
【００５３】
デスティネーションファイルネームは、リネームオペレーション又はハードリンク作成オペレーションを表すターゲットネームとして指定されるファイルネームである。ハードリンクとは、ボリューム上の同一の物理ビットが２つ以上のファイルネームを有する場合において、ファイルネームをエイリアシング（ａｌｉａｓｉｎｇ）することをいう。ボリューム上の同一の物理ビットに該当する幾つかのファイルネームは、それぞれハードリンクと呼ばれる。デスティネーションファイルネームは、リネーム又はハードリンクパラメータに従って、ファイルネームプロバイダによって生成される。一実施形態においては、このデスティネーションファイルネームは、２つのフォーマット、すなわちノーマライズドフォーマットか、オープンドフォーマットのうちの一方で提供することができる。本実施形態においては、これらファイルネームのフラグメントは、必ずしも全てが、初期に、ファイルネームからパースされるわけではない。ボリュームと、シェアフラグメントとが、初期に、このファイルネームからパースされる。一度ＦＩＳを指し示すポインタがこのフィルタドライバに戻されると、このフィルタドライバは、さらに、最終コンポーネント、拡張子、ストリーム、及び親ディレクトリのフラグメントを、ファイルネームからパースするように要求することができる。
【００５４】
一実施形態においては、デスティネーションファイルネームはフィルタマネージャによって提供されたデータ構造内にキャッシュされない（例えば、パーストリームコンテキスト）。その代わりに、デスティネーションファイルネームは、フィルタマネージャのオペレーション特有のデータ構造内にキャッシュされる（例えば、ＩＲＰ＿ＣＴＲＬ）。デスティネーションファイルネームは、リネーム又はハードリンク作成オペレーション中にキャッシュされる。一度ネームコールバックが利用されると、本処理はブロック９０４に進む。
【００５５】
ブロック９０４において、このフィルタマネージャは、ファイルネームプロバイダからファイルネームを受け取るが、この受け取りは、ファイルネームプロバイダが、アルティチュードがこの要求元のフィルタドライバより低い別のフィルタドライバか、このファイルシステムかに関わらず、行なわれる。本処理はブロック９０５に進み、図７のプロセス７００に戻り、ブロック７０５に進む。
【００５６】
図１０は、本発明に従ってパフォームされるファイルネームキャッシュプロセスの例を示す流れ図である。プロセス１０００は、図７のプロセス７００がブロック７０５に進むとき、ブロック１００１から開始される。本処理は判定ブロック１００２に進む。
【００５７】
判定ブロック１００２において、このフィルタマネージャが、ネームプロバイダから受け取ったファイルネームに対して、リネームが現在行なわれているか否かが判定される。リネームとは、ファイルリネーム、ディレクトリリネーム、又はハードリンク作成オペレーションをいう。フィルタマネージャが受け取ったファイルネームに影響を与えるリネームが開始されると、ＦＩＳのキャッシングがサスペンド（ｓｕｓｐｅｎｄ）され、このファイルネームに関係付けされているＦＩＳがキャッシュされないから、キャッシュの一部をパージ（ｐｕｒｇｅ）することができる。仮にリネーム中である場合には、本処理はブロック１００９に進み、ブロック１００９にて、このＦＩＳはキャッシュされず、本処理はブロック１０１０に進む。
【００５８】
しかしながら、仮にリネーム中でない場合には、本処理はブロック１００３に進み、特定のファイルネームのために作成されたＦＩＳに関係付けされているタイムスタンプ（ＴＳ）が、フィルタマネージャタイムスタンプ（ＦＴＳ）と比較される。このフィルタマネージャタイムスタンプは、最後のリネームプロシージャが完了したタイムに対応する。仮にＦＩＳが作成された後か、又は作成された時に、リネームが完了した場合（例えば、ＦＴＳ≧ＴＳ）には、このＦＩＳは、さらにファイルネームをケリーするためには、有効でない。しかしながら、仮にフィルタマネージャタイムスタンプがＦＩＳのタイプスタンプ未満である場合（例えば、ＦＴＳ＜ＴＳ）には、このＦＩＳは、さらにケリーするために、有効である。本処理は判定ブロック１００４に進む。
【００５９】
判定ブロック１００４においては、比較の結果に従って、ＦＩＳのタイムスタンプが、フィルタマネージャタイムスタンプ（ＦＴＳ）がＦＩＳのタイムスタンプ（ＴＳ）よりも少ないことを示すか否かが判定される。タイムスタンプが、ＦＩＳが今後のケリーに有効でないことを示す場合、プロセスはブロック１００９に続き、ＦＩＳはキャッシュされずに、本処理はブロック１０１０に進む。
【００６０】
しかし、タイムスタンプが、ＦＩＳが今後のケリーに有効であることを示す場合、本処理は判定ブロック１００５に進む。
【００６１】
判定ブロック１００５においては、ファイルに関係付けされているファイルネームの数が判定される。前述したように、ボリュームにストアされたファイルは、それぞれファイルに関係付けされている一意のファイルネームを表す複数のハードリンクとすることができる。したがって、仮にハードリンクの数が１を超える場合には、ファイルは１を超える数のファイルネームを有する。特定のファイルに関係付けされているファイルネームの数が１を超えないときは、本処理は判定ブロック１００６に進む。しかし、特定のファイル数に関係付けされているファイルネームの数が１を超える場合には、本処理はブロック１００８に進む。
【００６２】
判定ブロック１００６において、このフィルタマネージャがファイルネームプロバイダから受け取ったたファイルネームがノーマライズドフォーマットか否かが判定される。このフィルタマネージャに戻されたファイルネームがノーマライズドフォーマットであるときは、本処理はブロック１００７に進む。しかし、フィルタマネージャに戻されたファイルネームが、別のフォーマット、例えばショートファイルネーム又はオープンドファイルネームであるときは、本処理はブロック１００６に進む。
【００６３】
ブロック１００７において、このフィルタマネージャが受け取ったファイルネームに関係付けされているＦＩＳは、ストリームレベルでキャッシュされる。ストリームレベルでキャッシュされたＦＩＳにより、ＦＩＳを指し示すポインタを、特定のストリームに対応するファイルネームを要求する任意のフィルタドライバに戻すことができる。したがって、必要とする構造は少ない。というのは、特定のＦＩＳを、同一のストリームをシェアする複数のファイルオブジェクトのために、使用することができるからである。必要な構造が少なくなる。本処理はブロック１０１０に進み、ブロック１０１０にて、本処理は図７のプロセス７００に戻り、ブロック７０６に進む。
【００６４】
ブロック１００８において、このファイルマネージャが受け取ったファイルネームに関係付けされているＦＩＳは、ファイルオブジェクトレベルでキャッシュされる。ファイルオブジェクトレベルでキャッシュされたＦＩＳは、ファイルの特定のオープンインスタンスに適用される。ファイルオブジェクトレベルでキャッシュされたＦＩＳは、特定のファイルオブジェクトに対応する。たとえ特定のファイルオブジェクトが同一のストリームを第２ファイルオブジェクトとシェアできる場合であっても、このファイルオブジェクトレベルでストアされたＦＩＳは、特定のファイルオブジェクトに適用されるが、第２ファイルオブジェクトには適用されない。本処理はブロック１０１０に進み、ブロック１０１０にて、本処理は図７の処理７００に戻り、ブロック７０６に進む。
【００６５】
一実施形態においては、このＦＩＳがもはや有効でないときには、このＦＩＳに関係付けされているメモリ空間は割り振られない。このメモリ空間を解放する前に、このフィルタマネージャはこのＦＩＳに関係付けされている参照カウントを試験する。特定のＦＩＳに関係付けされたメモリは、参照カウントがゼロに達するまでは、解放されない。
【００６６】
リネーム
図１１は、本発明に従ってパフォームされるリネームプロセスの例を示す流れ図である。プロセス１１００は、リネームオペレーションが開始されるブロック１１０１から開始される。本処理は判定ブロック１１０２に進む。
【００６７】
判定ブロック１１０２において、現在のリネームプロセスがディレクトリのリネームであるか否かを判定する。ファイルネームのリネームに比べて、ディレクトリリネームにおいては、ディレクトリに関係付けされた全てのファイルのファイルネームが変更される。仮に現在のリネームプロセスがディレクトリのリネームを含まない場合には、本処理は判定ブロック１１０４に進む。しかし、仮に現在のリネームプロセスがディレクトリのネームを変更している場合には、本処理はブロック１１０３に進む。
【００６８】
ブロック１１０３において、ディレクトリネームの変更に応答して、当該ディレクトリに関係付けされているキャッシュが、フィルタマネージャと共にパージされる。キャッシュを参照するとき、このキャッシュには、特定のファイルネームのそれぞれのフォーマット（例えば、ノーマライズド、オープンド、ショート）に対するＦＩＳがそれぞれ含まれる。一実施形態においては、当該ディレクトリに関係付けされたキャッシュをパージするのは、ディレクトリリネームを反映するために、当該キャッシュを更新するのに利用されることになるであろうストリング比較よりも、効率的である。キャッシュをパージすることにより、その後に生成されるファイルネームが、ディレクトリのネーム変更を正確に反映できることを保証する。そして、これらフィルタドライバが、このフィルタマネージャに、新しいディレクトリネームを含むファイルネームをケリーするとき、当該キャッシュはリポピュレート（ｒｅｐｏｐｕｌａｔｅ）される。本処理はブロック１１０７に進み、このプロセスは終了する。
【００６９】
判定ブロック１１０４において、現在のリネームプロセスが、ハードリンク作成オペレーションに対応するか否かが判定される。ハードリンクが作成されると、このハードリンクは、ストリームレベルのファイルネームに影響を及ぼす。言い換えると、ストリームレベルでキャッシュされているＦＩＳは、このハードリンクが作成されたとき、当該ファイルの全てのオープンインスタンスに対しては、最早、有効ではない。仮にリネームプロセスがハードリンク作成オペレーションに対応する場合には、本処理はブロック１１０５に進む。
【００７０】
ブロック１１０５において、ハードリンク作成オペレーションに関係付けされたキャッシュが、ストリームレベルでパージされる。このハードリンクに従うファイルネームに対応しているＦＩＳは、ストリームレベルでは、最早、ストアされず（仮に、元々、ストリームレベルでストアされている場合には、図１０を参照）、ファイルオブジェクトレベルでストアされる。複数のハードリンクを有するファイルに関係付けされているＦＩＳは、ファイルの特定のオープンインスタンスにとっては有効であるが、ファイルの全てのオープンインスタンスにとって有効ではない。本処理はブロック１１０７に進み、本プロセスは終了する。
【００７１】
あるいはまた、仮にリネームプロセスがディレクトリリネーム又はハードリンク作成オペレーションに対応していない場合には、本処理はブロック１１０６に進む。
【００７２】
ブロック１１０６において、特定のファイルネームに関係付けされているキャッシュが、ストリームレベルとファイルオブジェクトレベルの両方でパージされる。したがって、ファイルネームの各フォーマットについてそれぞれのＦＩＳが、フィルタマネージャに関係付けされたデータ構造（図４及び５を参照）から削除される。本処理はブロック１１０７に続き、プロセスは終了する。
【００７３】
ファイルネームトンネリング
一実施形態においては、本発明には、ファイルシステムのファイルネームトンネリング機能を補償する機能が含まれる。ファイルネームトンネリングには、ファイルシステム内にストアされたファイルネームに含まれたロングネーム／ショートネームのペアが関係する。トンネリングは、オペレーティングシステムによってサポートされ、その結果として、ファイルシステムの任意のリード／ライトでトンネリング機能を利用することができる。ファイルネームトンネリングは、ロングネーム又はショートネームのいずれかが削除されたときに生じるが、ある時間間隔で、再び作成される。ファイルネームトンネリング機能により、ファイルのメタ情報（ｍｅｔａ―ｉｎｆｏ）を短い期間に持続できるファイルシステムを当てにするプログラムと互換性を有することができる。このファイルトンネリングは、削除又はリネームの後に生じ、新しいディレクトリエントリにメタ情報を再導入した後に生じる（仮に作成又はリネームがあって、当該ネームのファイルが短期間で再び現れる場合）。ネームがディレクトリから除去されると（リネーム又は削除）、そのショートネーム／ロングネームのペアと、他の属性、例えば作成時間がキャッシュにセーブされ、除去されたネームによってキー（ｋｅｙ）される。ネームがディレクトリに追加されると（リネーム又は作成）、リストア（ｒｅｓｔｏｒｅ）するための情報があるか否かをみるため、当該キャッシュがサーチされる。
【００７４】
図１２は、本発明に従ってパフォームされるファイルネームトンネリングプロセスであって、図７のプロセス７００と並行してランされるものを示す流れ図である。プロセス１２００はブロック１２０１から開始される。本処理は判定ブロック１２０２に進む。
【００７５】
判定ブロック１２０２において、この要求元フィルタドライバは、要求しているファイルネームがファイルネームトンネリングの候補であるか否かを認識する。ファイルネームトンネリングの候補は、８．３フォーマットの部分を含むファイルである。ファイルネームトンネリングは、ショートネーム（すなわち８．３フォーマットのファイルネーム）がファイルネームのノーマライズドバージョンに拡張されるとき、ファイルネームのノーマライズドバージョンに影響を及ぼす。ファイルに関係付けされているショートファイルネームを変更すると、これに従って、ノーマライズドネームも変更される。同様にして、ショートファイルネームが変更されない場合には、ノーマライズドファイルネームも変更されない。仮に当該ファイルネームがトンネリング候補でない場合には、本処理はブロック１２０５に進み、ファイルネームのＣＲＥＡＴＥオペレーションが正しく（ｓｕｃｃｅｓｓｆｕｌｌｙ）完了し、ファイルネームに対応するＦＩＳがキャッシュされる。しかし、仮にファイルネームがトンネリング候補である場合には、本処理は判定ブロック１２０３に進む。
【００７６】
判定ブロック１２０３において、ファイルネーム候補であるファイルネームに対してトンネリングが生じたか否かが判定される。トンネリングが生じていない場合には、本処理はブロック１２０５に進み、ファイルネームのためのＣＲＥＡＴＥオペレーションが正しく完了すると、ファイルネームに対応するＦＩＳがキャッシュされる。しかし、仮にファイルネーム作成中にファイルネームトンネリングが使用された場合には、本処理はブロック１２０４に進む。
【００７７】
ブロック１２０４において、作成されたファイルネームに関係付けされているＦＩＳは、フィルタマネージャによって提供されたデータ構造内にキャッシュされない。本処理はブロック１２０６に進み、本プロセスが終了する。
【００７８】
本明細書、例、及びデータにおいては、本発明のコンポーネントを製造し使用することを完全に説明するものである。本発明の多くの実施形態は、本発明の精神及び範囲を逸脱することなく実施できるから、本発明は、添付の特許請求の範囲を逸脱するものではない。
【図面の簡単な説明】
【００７９】
【図１】本発明の一実施形態において使用することができるコンピューティング装置の例を示す図である。
【図２】本発明を実施するための環境の例を示すブロック図である。
【図３】本発明に係るＮＴＦＳファイルシステムのデータ構造を示すブロック図である。
【図４】本発明に係るファイルオブジェクトとファイルマネージャデータ構造との間の関係を示すブロック図である。
【図５】本発明に係るフィルタマネージャに関係付けされた他のデータ構造を示すブロック図である。
【図６】本発明に従ってラベル付けされたフラグメントを有するファイルネームの例を示す図である。
【図７】本発明に従ってパフォームされるファイルネームケリープロセスの例を示す流れ図である。
【図８】本発明に従ってパフォームされるファイルネーム要求処理プロセスの例を示す流れ図である。
【図９】本発明に従ってパフォームされるファイルネーム生成プロセスの例を示す流れ図である。
【図１０】本発明に従ってパフォームされるファイルネーム情報構造キャッシュプロセスの例を示す流れ図である。
【図１１】本発明に従ってパフォームされるリネームプロセスの例を示す流れ図である。
【図１２】本発明に従ってパフォームされるファイルネームトンネリングプロセスの例を示す流れ図である。
【符号の説明】
【００８０】
１００　コンピューティング装置
１０２　プロセシングユニット
１０４　システムメモリ
１０５　オペレーティングシステム
１０６　プログラムモジュール
１０７　プログラムデータ
１０９　リムーバブルストレージ
１１０　ノンリムーバブルストレージ
１１２　入力装置
１１４　出力装置
１１６　通信コネクション
１１８　他のコンピューティング装置
１２０　フィルタマネージャ
【図１】
2004038960.tif 000003
【図２】
2004038960.tif 000004
【図３】
2004038960.tif 000005
【図４】
2004038960.tif 000006
【図５】
2004038960.tif 000007
【図６】
2004038960.tif 000008
【図７】
2004038960.tif 000009
【図８】
2004038960.tif 000010
【図９】
2004038960.tif 000011
【図１０】
2004038960.tif 000012
【図１１】
2004038960.tif 000013
【図１２】
2004038960.tif 000014
【外国語明細書】
2004038960.tif 000015
2004038960.tif 000016
2004038960.tif 000017
2004038960.tif 000018
2004038960.tif 000019
2004038960.tif 000020
2004038960.tif 000021
2004038960.tif 000022
2004038960.tif 000023
2004038960.tif 000024
2004038960.tif 000025
2004038960.tif 000026
2004038960.tif 000027
2004038960.tif 000028
2004038960.tif 000029
2004038960.tif 000030
2004038960.tif 000031
2004038960.tif 000032
2004038960.tif 000033
2004038960.tif 000034
2004038960.tif 000035
2004038960.tif 000036
2004038960.tif 000037
2004038960.tif 000038
2004038960.tif 000039
2004038960.tif 000040
2004038960.tif 000041
2004038960.tif 000042
2004038960.tif 000043
2004038960.tif 000044
2004038960.tif 000045
2004038960.tif 000046
2004038960.tif 000047
2004038960.tif 000048
2004038960.tif 000049
2004038960.tif 000050
2004038960.tif 000051
2004038960.tif 000052
2004038960.tif 000053
2004038960.tif 000054
2004038960.tif 000055