JP4359448B2 - ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法 - Google Patents

Description

本発明は、ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法に関する。

ファイルシステムドライバ（ＦＳＤ）は、ファイルシステムフォーマットを管理する。ＦＳＤは、カーネルモードでラン（run）するが、標準のカーネルモードドライバとは多くの点で異なっている。最も重要なのは、ＦＳＤ自体が、それぞれオペレーティングシステムによりファイルシステムドライバとして登録されることである。ファイルシステムドライバより上のレイヤーにあるフィルタドライバは、ファイルシステムフィルタドライバという。ファイルシステムフィルタドライバには、ファイルシステム要求をビュー（view）し、その要求を、オプションで、修正するか処理する（complete）能力が含まれる。ファイルシステムフィルタドライバには、暗号化、ウィルス検出、及び他のオペレーションをパフォームするフィルタドライバを含めることができる。

一般に、ファイルシステムフィルタドライバをインプリメントするコードは、大部分が、ファイルネーム検索とフォーマットとで占められる。ファイルシステム（例えば、ＮＴＦＳ、ＦＡＴ等）によって、許容されるファイルネームのサイズを変えることができる。例えば、ＮＴＦＳは、ファイルネームパスにある各コンポーネントが２５５キャラクタに限定され、合計のファイルネームの長さが６５５３６キャラクタに限定されるように、ネームスペシフィケーション（name specification）を設定する。ファイルネームには、Unicodeキャラクタを含めることができ、同様に、複数のピリオドと、埋込みスペース（embeded space）とを含めることができる。しかし、あるファイルシステムは、ファイルネームが８キャラクタ（非Unicode）に限定され、ファイルネームの後に、ピリオドと、３キャラクタの拡張子とが来るようになっており、これは一般に「８．３」フォーマットと呼ばれている。そこで、元々これらのファイルシステムためにライト（write）されたアプリケーションにおいても、８．３フォーマットか、又はこれと互換性のあるファイルネームを理解するできるようになっている。ＮＴＦＳのような他のファイルシステムにおいては、アプリケーションによりショートネーム（short name）が要求されたとき、当該ファイルシステムは、ロングネーム（long name）で作成されたファイルに代えて、８．３フォーマットのショートネームを生成する。ロングネームは、８．３フォーマットよりも長いファイルネームと、Unicodeキャラクタを含むファイルネームと、複数のピリオドキャラクタ又は１つのビギニングピリオド（beginning period）を有するファイルネームと、埋込みスペースを有するファイルネームとに対応する。ショートネームは、ファイル用のフル機能（fully functional）を有するエイリアス（alias）であり、ロングネームと同じディレクトリにストアされている。ロングネームもショートネームも、ファイルをオープンするか、リードするか、ライトするか、又はコピーするのに使用することができる。

ファイルネーム用のフォーマットは他にも存在し、ファイルシステムフィルタドライバは、これらフォーマットのうちのいずれかのフォーマットのファイルネームのケリーを開始することができる。ファイルネームは、Ｉ／Ｏオペレーション時にどのアクションを行うべきかをコントロールするため、ファイルシステムフィルタドライバにより使用されるのが一般的である。ユーザ又はアプリケーションは、ファイルネームを、多くの異なるフォーマットのうちの１つで、指定することができる。ファイルシステムフィルタドライバにおいては、当該ファイルネームがそのオペレーションに関係しているか否かを試験するため、当該ファイルネームを標準フォーマットにノーマライズ（normalize）することもある。ファイルシステムフィルタドライバは、一般に、ファイルネームをパース（parse）してフラグメント（fragment）にする。例えば、ウィルスを検出できるファイルシステムフィルタドライバは、ファイルネームの拡張子のタイプ（例えば、.exe、.dll等）に最も関心を持ち、ファイルネームから拡張子をパースしようとする。現在では、複数のフィルタドライバが、それぞれ、自分に、１つのＦＳＤにアタッチ（attach）することができるが、各フィルタドライバが、当該ＦＳＳに対してファイルネームをケリーするから、リソースを消費（consume）する。各ファイルシステムフィルタドライバには、コードが含まれ、これらファイルシステムフィルタドライバは、ファイルネームを管理し操作するため、プロセスタイム(process time)をファイルネームの管理及び操作に当てる。

本発明によれば、ファイルシステムフィルタドライバ（以下「フィルタドライバ」という。）用のファイルネームオペレーションを処理し、償却する（amortize）ためのファイルシステムフィルタマネージャ（以下「フィルタマネージャ」という。）を含む。フィルタマネージャは、各フィルタドライバに共通のファイルネームの検索及びフォーマット化機能を提供する。さらにフィルタマネージャは、１つ以上のフィルタドライバでシェアできるネーム情報のキャッシュを提供する。キャッシュ、ファイルネーム検索、及びフォーマット化機能は、フィルタマネージャ内でのファイルネーム管理を統合することによって、ファイルシステム内でのファイルネーム管理の効率を上げるものである。

本発明は、ファイルシステム内のフィルタドライバ用のファイルネームを管理する。本発明は、フィルタドライバからのファイルネームケリーを処理するフィルタマネージャを含む。フィルタマネージャは、ドライバスタック内のフィルタドライバからのファイルネーム要求を受け取って処理する。フィルタマネージャは、前に生成されたファイルネームに関するファイルネーム情報構造のキャッシュを維持する。各ファイルネーム情報構造は、ファイルネームのフラグメントを指し示すポインタを含むポインタリストを備えている。フィルタマネージャは、第一に、フィルタドライバによるファイルネーム要求に対応するファイルネーム情報構造が前に生成されたか否かを判定するため、キャッシュを試験する。このようなファイルネーム情報構造が存在しない場合には、フィルタマネージャは、そのファイルネームのファイルネームプロバイダをコールする。ファイルネーム情報構造が作成されていた場合には、フィルタマネージャは、ファイルネーム情報構造に関係付けされている参照カウント及びタイムスタンプを更新する。参照カウントは、ファイルネーム情報構造が少なくとも１つのフィルタドライバによって使用されている限り、ファイルネーム情報構造が有効であることを保証するものである。タイムスタンプは、ファイルがリネーム（rename）されるとき、又はその後のオペレーションがファイルネームに影響を与えるとき、ファイルネーム情報構造が、ファイル用の現在のファイルネームを反映することを保証するものである。ついで、フィルタマネージャは、対応するファイルネーム情報構造を指し示すポインタを、要求側フィルタドライバに戻す。

簡潔に言えば、本発明は、ファイルシステムにおいて、フィルタドライバ用のファイルネームを管理する方法及びシステムに関する。本発明には、フィルタドライバからのファイルネームケリーをハンドル（handle）するフィルタマネージャが含まれる。フィルタマネージャは、要求されたファイルネームのタイプに対応するファイルネーム情報構造を指し示すポインタを、要求側フィルタドライバに戻す。このフィルタマネージャは、次のようなファイルネーム情報構造のキャッシュも管理し、フィルタドライバに対して行うファイルネームケリーを償却する（amortize）。このファイルネーム情報構造には、種々のフィルタドライバでシェア（share）できる情報が含まれる。このフィルタマネージャにキャッシュ機能があるので、ファイルシステムフィルタドライバがファイルネームの所望の部分を取り出すのに要求されるファイルネームオペレーションの数が減少し、これにより、効率が良くなり、ファイルシステム内でのファイルネームケリーのオーバヘッドが減少する。

本明細書及び特許請求の範囲においては、当該コンテキストが明確にそうでないと述べない限り、次の用語は、本明細書に明示的に関係付けをした意味を有するものとする。

「ＦＩＳ（File Information Structure）」とは、フィルタマネージャに関係付けをしたデータ構造であって、少なくとも一実施形態においては、ボリューム（volume）にストアされた特定のファイルネームのネームフラグメント（name fragment）を指し示すポインタをストアするデータ構造をいう。「ネームフラグメント」とは、ファイルネームの一部をいう。例えば、ファイルネームには、拡張子（例えば、.txt、.dll、.docなど）が含まれるのが典型的である。この拡張子は、ネームフラグメントの１つのタイプを表す。

「アルティチュード（altitude）」とは、特定のフィルタドライバが、アプリケーションと、ボリュームを管理するファイルシステムとの間で送信されるＩＲＰ（Input/Output Request Packet）に応答する順番（order）をいう。当該ファイルシステムにおいて、他のフィルタドライバよりアルティチュードの高いフィルタドライバは、「further away」といわれ、当該ＩＲＰがアプリケーションから送信されるとき、ＩＲＰに関係付けされたオペレーションを、これら他のフィルタドライバより早くハンドルする。これに対して、当該ＩＲＰがファイルシステムから送信されるとき、ＩＲＰに関係付けされたオペレーションを、他のフィルタドライバより遅く処理する場合、当該フィルタドライバのアルティチュードは低い。これらＩＲＰとは、多くの場合、ＩＯサブシステムにおいて使用されるデータ構造をいうが、これらにはＮＴＦＳのようなファイルシステムが含まれる。しかしながら、たとえＩＲＰのみを参照できるとしても、当然、本発明に係るフィルタマネージャは、当該ＩＲＰを、別のデータ構造、例えば、所定のオペレーションをフィルタに提示するためのCallback Data構造に、変換することができる。

「ファイルネームプロバイダ」とは、ファイルシステムか、又はファイルに代替のファイルネームを提供するために登録された特定のフィルタドライバか、のいずれかをいう。

オペレーティング環境の例
図１を説明する。本発明をインプリメントしたシステムの例には、コンピューティング装置１００のようなコンピューティング装置が含まれる。非常に基本的な構成においては、コンピューティング装置１００には、少なくとも１つのプロセシングユニット１０２と、システムメモリ１０４とが含まれるのが典型的である。正確な構成と、コンピューティング装置のタイプとに応じて、システムメモリ１０４は、（ＲＡＭのような）揮発性メモリか、（ＲＯＭ、フラッシュメモリのような）不揮発性メモリか、又はこれらメモリを組み合わせたものとすることができる。システムメモリ１０４には、オペレーティングシステム１０５と、１つ以上のプログラムモジュール１０６と、プログラムデータ１０７とが含まれるのが典型的である。さらに、オペレーティングシステム１０５には、本発明に係るフィルタマネージャ１２０を含めることができる。この基本的な構成は、図１において、破線１０８内のコンポーネントで図示してある。

コンピューティング装置１００は、フィーチャ（feature）又は機能を追加することができる。例えば、コンピューティング装置１００には、追加の（リムーバブル及び／又はノンリムーバブル）データストレージ装置、例えば、磁気ディスク、光ディスク、又はテープを含めることもできる。このような追加のストレージ装置としては、図１において、リムーバブルストレージ１０９と、ノンリムーバブルストレージ１１０が図示してある。コンピュータ記憶媒体には、揮発性及び不揮発性、リムーバブル及びノンリムーバブルの媒体であって、情報を記憶するための方法又は技術、例えば、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータを、インプリメントした媒体を含めることができる。システムメモリ１０４、リムーバブルストレージ１０９、及びノンリムーバブルストレージ１１０は、全て、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリその他のメモリ技術か、ＣＤ−ＲＯＭ、ＤＶＤ（digital versatile disk）その他の光記憶装置か、磁気カセット、磁気テープ、磁気ディスク記憶装置その他の磁気記憶装置か、あるいは、所望の情報をストアするために使用可能な媒体であってコンピューティング装置１００がアクセス可能な他の媒体が含まれるが、これらに限定されるものではない。このようなコンピュータ記憶媒体は、コンピューティング装置１００の一部とすることができる。コンピューティング装置１００は、入力装置１１２、例えばキーボード、マウス、ペン、音声入力装置、タッチ入力装置を有することができる。出力装置１１４、例えばディスプレイ、スピーカ、プリンタも含めることができる。これらの装置は、当分野で周知のものであるから、ここでは詳細に述べない。

コンピューティング装置１００は、通信コネクション１１６も含むことができ、これにより、他のコンピューティング装置１１８と、例えばネットワークを介して、通信することができる。通信コネクション１１６は、通信媒体の一例である。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又は変調データ信号、例えば、搬送波その他のトランスポートメカニズム上の他のデータにより具現化できるのが典型的であり、この通信媒体には、情報配信媒体（information delivery media）が含まれる。「変調データ信号」とは、情報をエンコードして信号中に入れて設定（set）するか変化させた１つ以上の特性を有する信号をいう。例えば、通信媒体には、ワイヤード（wired）媒体、例えば、ワイヤード（wired）ネットワーク又はダイレクトワイヤード接続と、ワイヤレス（wireless）媒体、例えば、音波、ＲＦ、赤外線等が含まれるが、これらに限定されるものではない。本明細書において使用されるコンピュータ可読媒体という用語には、記憶媒体と、通信媒体とが含まれる。

フィルタドライバ構造とファイルシステム
図２は、本発明を実施するための環境例を示すブロック図である。図２に示す環境は、ファイルシステムのためのＩＯ（Input/Output）サブシステム環境２００であって、このＩＯサブシステム環境２００には、本発明に係るフィルタマネージャ１２０が含まれる。

ファイルシステム環境２００には、ユーザモードでオペレートするアプリケーション２０２と、カーネルモードでオペレートするＮＴＦＳファイルシステム２２０とが含まれる。ここにおいては、ＮＴＦＳのコンテキストで記載するが、当然、本発明は、他の多くのファイルシステム、例えばＦＡＴ、ＦＡＴ３２、ＥＸＴ２、ＨＰＦＳ等に対しても等しく適用可能である。

ＮＴＦＳ２２０とアプリケーション２０２との間に、カーネルモードでオペレートするフィルタドライバ構造２１０がある。フィルタドライバ構造２１０には、フィルタマネージャ１２０が含まれるとともに、複数のフィルタドライバ（例えば、２１２Ａ〜Ｃ）からなるフィルタドライバスタックが含まれる。ＮＴＦＳ２２０は、ボリューム２３０にストアされたファイルシステム構造を管理するため、システムメモリ１０４内において、複数のデータ構造（例えば、２４０）を維持している。データ構造２４０については、以下に、図３を参照して詳細に述べる。ボリューム２３０には、ファイルレコードのアレイ（array）を提供するＭＦＴ（master file table）２３２が含まれるが、このファイルレコードのアレイには、ボリューム２３０が有する各ファイルに対して１つのレコードが含まれ、レコードとしてはＭＦＴ２３２に対するレコードもある。例えば、ＭＦＴ２３２には、ファイルネーム属性２３４のレコードを含めることができ、追加のファイルネーム属性２３４を含む他のファイルレコードを指し示すポインタを含めることができる。

ＩＯサブシステム環境２００においては、フィルタドライバ２１２Ａ〜Ｃにより、ＮＴＦＳファイルシステム２２０に機能が追加される。前に述べたシステムにおいては、フィルタドライバ２１２Ａ〜Ｃは、カーネルモードでオペレートしているＮＴＦＳ２２０と、ユーザモードでオペレートしているアプリケーション２０２との間で送信さるＩＲＰをインタセプト（intercept）する。例えば、アプリケーションは、ファイルを作成するためのファンクション（function）（例えば、CreateFile）をコールしてファイルにアクセスする。これに応答して、指定されたタイプのＩＲＰが生成される。この生成されたＩＲＰにより、オープンされているファイルのネームをストアするファイルオブジェクトが作成され、ついで、このＩＲＰがフィルタ構造２１０に渡される。フィルタドライバ２１２Ａ〜Ｃは、それぞれ、指定された機能をインプリメントするため、このＩＲＰが参照するファイルネームをルックアップ（look up）することができる。そして、ハンドルが、コーリングチェーン（calling chain）を介して戻され、戻りパラメータ（return parameter）として、アプリケーション２０２に到達することになる。

フィルタドライバの機能としては、フィルタドライバがＩＲＰを受け取ったとき、ＩＲＰに関係付けされているファイルのファイルネームを知ったか否かに依存する機能がある。例えば、ウィルス検出用のフィルタドライバは、ファイルネーム中に「.exe」又は「.dll」の拡張子の付いたファイルに集中することができる。あるいはまた、暗号化向けのフィルタドライバは、特定パスのファイルの暗号化に集中することができる。このＩＲＰには、このＩＲＰに関係付けされているファイルのフル（full）ファイルネームが含まれていなくてもよい。例えば、アプリケーション２０２からのファンクションコールの、リード、ライト、又は作成においては、ファイルネームではないファイルＩＤを指定することができる。このファイルＩＤとは、ボリューム２３０が有するファイルを一意に識別する数字である。CREATE又はＯＰＥＮオペレーションのために、ユーザがファイルを識別するのに使用するファイルネーム又はＩＤは、当該ファイルにとって、pre-CREATE期間の間、有効である。CREATE又はＯＰＥＮオペレーションの後、ファイルオブジェクトには、ＮＴＦＳ２２０が、ファイルのファイルネームを使用せずに、どのファイルが参照されているかを識別できるデータ構造が、含まれる。したがって、仮にフィルタドライバ（例えば、２１２Ａ〜Ｃ）が、pre-CREATE期間の後に、ファイルネームが必要な場合には、ＮＴＦＳ２２０にファイルネームをケリーする。フィルタドライバ２１２Ａ〜Ｃは、オペレーションを完了させるため、ＮＴＦＳ２２０へのファイルネームのケリーを開始することを要求することができる。

本発明においては、フィルタドライバスタック（すなわち、フィルタドライバ２１２Ａ〜Ｃ）によりシリアルに渡されるＩＲＰに代えて、当該ＩＲＰが、フィルタマネージャ１２０に直接渡される。ついで、フィルタマネージャ１２０は、各フィルタドライバ２１２Ａ〜ＣにＩＲＰを通知するから、当該ＩＲＰに関係する機能を含むフィルタドライバは、フィルタマネージャ１２０と（例えば、コールバックにより）、インタラクトすることができる。フィルタドライバ２１２Ａ〜Ｃがフィルタマネージャ１２０とインタラクトできる１つの方法は、指定されたオペレーションを完了するため、フィルタマネージャ１２０に対してファイルネームをケリーしてインタラクトする方法である。フィルタマネージャ１２０は、フィルタドライバ２１２Ａ〜Ｃによるファイルネームの要求を管理する。

フィルタマネージャ１２０により、３つのフォーマット、すなわち、ノーマライズド（Normalized）、ショート（Short）、又はオープンド（Opened）のうちの１つのフォーマットで、ファイルネームをケリーすることができる。ノーマライズドファイルネームは、ショートネームが拡張されたものであり（すなわち、ノーマライズドファイルネームはロングネームである）、ディレクトリのルートからのファイルのフルパスを有するから、マウントポイントが解決（resolve）される（図１０に関する説明を参照されたい）。オープンドファイルネームには、ファイルをオープンするために使用されたフォーマットのファイルネームが含まれる（例えば、ショートネーム又はロングネームのいずれかを含むことができる）。ショートファイルネームには、ファイルのフルパスの最終コンポーネントであって、８．３フォーマット（例えば、「filename.ext」）のファイルネームのみが含まれる。

フィルタマネージャ１２０は、プロセス中の特定時間においては、あるファイルネームフォーマットをケリーすることができない。例えば、アプリケーション２０２によってファイル作成オペレーション（すなわち、ファイルオープンオペレーション）が開始されたときは、オペレーションがＮＴＦＳ２２０に達するまでは、新しく作成されたファイルのファイルネームが有効であるか否かを判定することが、恐らく、不可能になる。この期間の間は、フィルタマネージャ１２０はショートファイルネームフォーマットで、ファイルネームをケリーすることはできない。これは、ショートファイルネームフォーマットの有効性（validity）が疑わしいからである。

図３は、本発明に係るＮＴＦＳファイルシステムによって維持されるデータ構造２４０の例を示す。データ構造２４０には、ファイルオブジェクト３１０及び３１２と、ストリームコントロールブロック（ＳＣＢ）３２０と、ファイルコントロールブロック（ＦＣＢ）３３０とが含まれる。

ファイルは、１つ以上のデータストリームにより構成され、そのうちの１次データストリームをネーム無し（unnamed）とすることができる。このファイルシステムは、ＳＣＢ（例えば、３２２及び３２４）を使用して、ファイルの各データストリームを一意に識別する。例えば、ＳＣＢ３２２は、ファイルオブジェクトのうちの１つのファイルオブジェクト（例えば、図３に３１０で示す）に対しては、１次のネーム無しストリームであり、ＳＣＢ３２４は、このファイルオブジェクトに対しては２次のネーム付きストリームである。ファイルオブジェクト（３１０、３１２）は、ファイルの特定データストリーム（ネーム付き又はネーム無し）のオープンに対応する。このファイルシステムは、ファイルオブジェクト（３１０、３１２）から、ＭＦＴ２３２によって提示されているボリュームが有するファイルのロケーションを指し示すポインタを幾つか作成する。ファイルオブジェクト３１０及び３１２は、それぞれオープンファイルの単一のインスタンスを表すものであるが、コール側アプリケーションがリード又はライトを試みているファイルに対応するＳＣＢ（stream control block）３２０を指し示している。特定のファイルに対するＳＣＢは、共通のファイルコントロールブロック（例えば、３３０）を指し示している。ＦＣＢ３３０には、ＭＦＴ２３２のファイルのレコードを指し示すポインタが含まれる。

図４は、ファィルオブジェクトと、本発明に係るフィルタマネージャデータ構造との間の関係を示す。図３に関して述べたように、ファイルオブジェクト３２０はファイルのオープンインスタンスを表す。あるタイプのドライバ、例えばフィルタドライバは、ファイルオブジェクト３２０内のフィールドのうちの幾つかを利用することができる。本発明は、ファイルオブジェクト３２０内のフィールドを、ポインタ用に使用している。ポインタ（Pvoid FsContext）は、FsContext共通ヘッダ４１０というデータ構造であって、ロックと、パーストリームコンテキスト（per stream context）のリンクされたリストとが含まれるデータ構造を指し示している。このFsContext共通ヘッダ４１０は、ファイルシステムが「パーストリームコンテキスト」機能をサポートするか否かを指定する。「パーストリームコンテキスト」とは、ファイルシステム（ＮＴＦＳファイルシステムに存在するようなファイルシステム）により、他のドライバが幾つかの情報をこのストリームに関係付けすることができるか否かをいう。FsContext共通ヘッダ４１０は、フィルタドライバがポピュレート（populate）できるパーストリームコンテキストのリンクされたリストに、指定された機能のための情報を提供する。FsContext共通ヘッダ４１０は、ファイルシステムに応じて、ファイルコントロールブロック（ＦＣＢ）又はストリームコントロールブロック（ＳＣＢ）のいずれかとすることができる。本発明において、ＮＴＦＳファイルシステムに関しては、FsContext共通ヘッダ４１０は、パーストリームコンテキストのリンクされたリストを含むＳＣＢであって、コンテキストをファイルオブジェクト（例えば、３２０）に提供するためのものである。パーストリームコンテキスト４１２には、それぞれ、２つのキー（Key１、Key２）が含まれるとともに、フィルタマネージャによって維持されるフィルタマネージャデータ構造４２０を指し示すポインタ（pVoid FMDS）が含まれる（図２を参照）。フィルタマネージャデータ構造４２０は、フィルタドライバからの要求に応答して作成された各ファイルネームのためのＦＩＳ（filename information structure）（図５を参照）をストアするためのキャッシュである。各フィルタマネージャデータ構造４２０は、さらに、各ＦＩＳに関係付けされたファイルネーム（例えばノーマライズドネーム、オープンドネーム、及びショートネーム）のフォーマットに従って、ネームキャッシュデータ構造４２２Ａ〜Ｃに編成される。

図５は、本発明に係るフィルタマネージャに関係付けされたデータ構造の例を示す。図４に示した各ネームキャッシュデータ構造４２２Ａ〜Ｃには、ツリー構造が含まれる。一実施形態においては、ツリー構造はスプレイ（splay）ツリー構造である。スプレイツリーは、データベースにファイルを配置したり、データベースからファイルを突き止めたりすることに関連して共通に使用される。

本発明においては、当該ツリー構造のノード５１０は、特定のＦＩＳ５２０を指し示すことができる。ノード５１０は、２つのキー（Key１、Key２）でインデックス付けされており、ノード５１０には、ファイルネームに対応する適正なＦＩＳを指し示すポインタ（pVoid FIS）が含まれる。図８に関連して説明するが、本発明においては、Key１は要求されたファイルネームのファイルオブジェクトに対応し、Key２はファイルネームのファイルネームプロバイダに対応する。

ＦＩＳ５２０には、プライベートヘッダ５２２と、ファイルネームポインタリスト５２４とが含まれる。特定ファイルネーム、すなわちノーマライズド、オープンド、又はショートに対して、異なるＦＩＳ５２０が可能である。言い換えれば、特定ファイル用のノーマライズドファイルネームと、これと同一のファイル用のショートファイルネームが、それぞれ異なるＦＩＳ５２０で表される。

プライベートヘッダ５２２には、参照カウント、タイムスタンプ、その他のデータに関するデータが含まれる。この参照カウントは、ＦＩＳ５２０が、フィルタドライバによって参照される限り、メモリに維持されることを保証する。このタイムスタンプは、ファイルがリネームされるか、又はリネーム後のオペレーションがファイルネームに影響を及ぼすとき、ＦＩＳ５２０が当該ファイルに対して現在のファイルネームを反映させる、ことを保証する。このタイムスタンプについては、図１０を参照して詳細に説明する。

ファイルネームポインタリスト５２４には、単一のメモリバッファにある同一のファイルネームのうちの指定された複数のフラグメントをそれぞれ指し示すポインタが含まれる。各フラグメントは、当該ファイルネームの一部を構成するUnicodeストリングに対応する（図６を参照）。これらポインタは、ファイルネームを備えたキャラクタのアレイを示すインデックスとしてオペレートする。当該ファイルネームがフィルタマネージャによってパースされるから、当該ファイルネームのフラグメントを試験することを望むフィルタドライバは、当該ファイルネームを個々にパースする必要はない。

図６は、本発明によりラベル付けされたフラグメントを有するファイルネームの例を示す。このインプリメンテーションにおいては、ファイルネーム６００には、要求があれば提供することができるフィルタマネージャ（図２を参照）によって認識された６つのフラグメント（６１０、６２０、６３０、６４０、６５０、６６０）が含まれる。各フラグメントは、図５のファイルネームポインタリスト５２４にリストされているポインタのうちの１つによって、指し示されている。これらフラグメントには、ボリューム６１０、シェア（Share）６２０、親ディレクトリ６３０、最終コンポーネント６４０、拡張子６５０、及びストリーム６６０が含まれる。

ボリューム６１０とは、当該ファイルネームのうち、当該ファイルをストアする論理ボリュームを記述した部分をいう。ネットワークからのファイルにおいて、ボリューム６１０とは、当該ファイルネームのうち、リモートファイルにアクセスするのに使用されるネットワークプロバイダを記述する部分をいう（例えば、＼Device＼LanmanRed＼）。

シェア６２０は、ローカルファイル用のＮＵＬＬストリングである。ただし、リモートファイルにおいて、シェア６２０とは、当該ファイルネームのうち、当該ファイルネームをネットワークプロバイダのネームスペースにストアするパスを記述する部分をいう。

親ディレクトリ６３０とは、最終コンポーネントを除去して得られるファイルネームのうちのフルパスを記述した部分をいう。

ファイルネームにおいて各コンポーネントは、「／」又は「＼」で区切られているが、最終コンポーネント６４０とは、ファイルネームストリングの末端にあるコンポーネントであってストリーム６６０を含むものをいう。

拡張子６５０とは、当該ファィルネームのうち、最後の「．」から任意のストリームまでの部分をいう。

ストリーム６６０とは、当該ファイルネームのうち、最終コンポーネントにある最初の「：」以降の部分をいう。

一実施形態において、あるフラグメントにあっては、その特定フラグメントを取得するとオーバヘッドコストが高くなるので、あるネームタイプ（例えば、ショートネーム）に従ってオープンされたファイルには利用できない。

フォーマット化、パース、及びキャッシングのためのプロセス
図７は、本発明に従ってパフォームされるファイルネームケリープロセスを示す流れ図である。このプロセスは、開始ブロック７０１から開始され、開始ブロック７０１において、図２のフィルタマネージャ１２０によってＩＲＰが受け取られ、このＩＲＰが、フィルタドライバ２１２Ａ〜Ｃのうちの１つに通知される。プロセス７００は、ブロック７０２に進む。

ブロック７０２にて、フィルタマネージャ１２０は、通知を受けたフィルタドライバから、特定ファイルネームの要求を受け取る。一実施形態においては、このファイルネーム要求は、フィルタマネージャ１２０が受け取ったＩＲＰに関係して行う。他の実施形態においては、このフィルタドライバが、このＩＲＰに無関係なオペレーションの一部として、ネーム要求を開始することができる。ファイルネーム要求がフィルタマネージャによって受け取られると、このフィルタマネージャはファイルネームを検索する。ファイルネーム要求処理プロセスの例については、図８を参照して説明する際に、詳細に説明する。本処理は、判定ブロック７０３に進む。

判定ブロック７０３において、当該ファイルネームに対応するＦＩＳが、このフィルタマネージャに対応するデータ構造（図４及び５を参照）内に前もってキャッシュされているか否かを判定する。仮にファイルネーム要求に対応するＦＩＳが前もってキャッシュされている場合には、本処理はブロック７０６にジャンプする。他方、仮にファイルネーム要求に対応するＦＩＳが以前にキャッシュされていない場合には、本処理はブロック７０４に進む。

ブロック７０４において、このフィルタマネージャは、ファイルネームのために、ファイルネームプロバイダをコールする。特定フィルタドライバのためのファイルネームプロバイダは、ボリュームにある同一の物理ファイルと異ならせることができる。ファイルネームプロバイダとしてオペレートするフィルタドライバは、当該ファイルネームを、アルティチュードの高いフィルタドライバに提供するが、通常、アルティチュードの低いフィルタドライバには提供しない。例えば、第１フィルタドライバのアルティチュードを、ファイルネームプロバイダとしてオペレートしている第２フィルタドライバよりも高くすることができる。第１フィルタドライバのためのファイルネームプロバイダは、第２フィルタドライバとなる。しかし、仮に第３フィルタドライバのアルティチュードが第２フィルタドライバよりも低い場合には、第２フィルタドライバは、第３フィルタドライバのためのファイルネームプロバイダとならない。当該ファイルネームを提供するファイルネームプロバイダをコールするプロセスの例については、図９を参照して説明する際に、詳細に説明する。本処理はブロック７０５に進む。

ブロック７０５において、ファイルネームプロバイダによって生成されたファイルネームためのＦＩＳが、フィルタマネージャによって提供されるデータ構造内にキャッシュされ、要求元のフィルタドライバにされる。フィルタマネージャ用のキャッシュのハンドリング（handling）は、ファイルネームに現在適用されているプロセスと、ファイルネームのタイプその他の要素とに依存する。ＦＩＳを指し示すポインタは、フィルタマネージャによって、ファイルネーム要求を開始したフィルタドライバに戻される。ポインタは、フィルタドライバがＦＩＳのファイルネームポインタリストにアクセスすることによって、ネームフラグメントにアクセスできるようにするものである。ＦＩＳをキャッシュしてこれを要求元のフィルタドライバに戻すための例示的プロセスについては、図１０を参照して説明する際に、詳細に説明する。本処理はブロック７０６に進む。

ブロック７０６において、フィルタドライバが、現在、ＦＩＳを使用中であることを反映させるため、各ＦＩＳに関係付けされている参照カウントが更新（又はインクリメント）される。一実施形態においては、図５に示したように、参照カウントが、各ＦＩＳのプライベートヘッダに含められる。このＦＩＳに関係付けされているメモリは、参照カウントがゼロを超えていれば、有効である。任意のフィルタドライバが、このＦＩＳへの参照を獲得すると、この参照カウントがインクリメントされる。各フィルタドライバが、このＦＩＳへの参照を解放するとき、ネット（net）カウントがデクリメントされる。このネットカウントがゼロになると、このＦＩＳが削除され、当該メモリが消去される。参照カウントは、特定のＦＩＳと、このＦＩＳに関係付けされているファイルネームとを含むメモリが、少なくとも必要な限度において有効である、ことを保証する。本処理はブロック７０７に進み、ブロック７０７において本処理が終了する。

一実施形態においては、プロセス７００は、CREATEオペレーションに対しては、異なるオペレートをする。CREATEオペレーションにおいては、当該ファイルシステムによって当該ファイルがまだオープンされていないので、当該ファイルのＳＣＢにリンクされたキャッシュデータ構造（例えば、ＦＩＳ）は、まだ生成されていない。フィルタドライバによってpre-CREATE期間において要求されたファイルネームにあって、このファイルネームは、このファイルオブジェクトに関係付けされているオペレーションデータ構造（例えば、IRP_CTRL）キャッシュを試験することにより生成される。仮にオペレーションデータ構造キャッシュからファイルネームが生成できない場合には、ファイルネームプロバイダに対してこれらを生成するように要求される（図８を参照）が、ファイルネームは、post-CREATE期間に達するまで、オペレーションデータ構造キャッシュにキャッシュされる。post-CREATEにおいて、仮にCREATEオペレーションが正しく完了した場合には、キャッシュデータ構造が生成される。仮にこのファイルネームが有効であり（図１０を参照）、トンネリング（tunneling）が発生していない（図１２を参照）場合には、ファイルネームがキャッシュされる。

図８は、本発明に従ってパフォームされるファイルネーム要求処理プロセスの例を示す流れ図である。図７のプロセス７００がブロック７０２に進むと、本処理がブロック８０１から開始される。本処理はブロック８０２に進む。

ブロック８０２において、このフィルタマネージャは、当該ファイルネームに関係付けされているファイルオブジェクトと、ファイルネームに対して要求されたフォーマット（例えば、ノーマライズド、オープンド、又はショート）とが含まれるファイルネームに対する要求を、フィルタドライバから受け取る。本処理はブロック８０３に進む。

ブロック８０３において、このフィルタマネージャは、ファイルネーム要求を行ったフィルタドライバから、ファイルネームプロバイダを判定する。前述したように、第１フィルタドライバは、アルティチュードが、ファイルネームプロバイダとしてオペレートしている第２フィルタドライバよりも高いが、この第２フィルタドライバを、そのファイルネームケリーのためのファイルネームプロバイダとして利用する。ドライバスタック内におけるフィルタドライバの順番は、このフィルタマネージャによって予め決定される。加えて、ファイルネームプロバイダとしてオペレートすることを望むフィルタドライバは、フィルタマネージャとともに、予め登録される。仮に要求元のフィルタドライバのアルティチュードが、指定されたファイルネームプロバイダよりも高い場合には、そのインスタンスのファイルネームプロバイダは、そのアルティチュードが、要求元フィルタドライバに最も近いが、要求元フィルタドライバよりも低いファイルネームプロバイダである。仮に要求元フィルタドライバが、他に、アルティチュードの低いファイルネームプロバイダとしてオペレートしているフィルタドライバを有していない場合には、このファイルシステムは要求元フィルタドライバのためのファイルネームプロバイダとしてオペレートする。一度要求元フィルタドライバのためのファイルネームプロバイダが決定されると、本処理はブロック８０４に進む。

ブロック８０４において、このフィルタマネージャによって提供されたデータ構造内に既にキャッシュさせることができるファイルネーム要求に対応するＦＩＳをサーチすることができる。図４に関連して既に述べたが、このデータ構造は、要求されたファイルネームフォーマット（例えば、ノーマライズド、オープンド、又はショート）に従って編成される。要求されたファイルネームフォーマットに対応するデータ構造は、２つのキー（Key１、Key２）（図５を参照）に従ってサーチされる。第１キーは、当該ファイルの特定のオープンインスタンスに関係付けされているファイルオブジェクトである。このファイルオブジェクトは、ＦＩＳが、同一のストリームレベル又はファイルオブジェクトレベルで、キャッシュされるか否かを指定するのを、支援する。これについては図１０を参照して詳細に述べる。第２キーは、ブロック８０３で識別されたファイルネームプロバイダである。仮にＦＩＳが予めストアされている場合には、２つのキー（Key１、Key２）に従って、フィルタドライバデータ構造をサーチして、現行のＦＩＳを突き止める。本処理はブロック８０５に進み、ついで図７のプロセス７００に戻り、ブロック７０４に進む。

図９は、本発明にしたがってパフォームされるファイルネーム生成プロセスの例を示す流れ図である。プロセス９００は、図７のプロセス７００がブロック７０４に進むと、ブロック９０１から開始される。本処理は判定ブロック９０２に進む。

判定ブロック９０２において、アルティチュードの低いフィルタドライバがファイルネームプロバイダとしてオペレートしているか否かを判定する。オペレートしていない場合には、このファイルシステムによってファイルネームが提供され、本処理はブロック９０６に進む。しかし、仮にアルティチュードの低いフィルタドライバがフィルタドライバとしてオペレートしている場合には、本処理はブロック９０３に進む。

ブロック９０３において、このファイルネームプロバイダからファイルネームを検索するため、ネームコールバックが利用される。使用されるコールバックのタイプは、デスティネーションファイルネームが要求元フィルタドライバによって要求されたか否かに依存する。このファイルネームプロバイダは、２つのコールバックを登録する。これら２つのコールバックのうちの一方のコールバック、すなわちCreateDestinationNameCallbackは、ファイルネームプロバイダよりも高いフィルタドライバによって、デスティネーションネームが要求されたとき、コールされる。その他方のコールバック、すなわちCreateFileNameCallbackは、ファイルネームプロバイダよりも高い第２フィルタによって、ファイルネーム（デスティネーションファイルネームにおいてはない）が要求されたとき、第１フィルタドライバをコールする。

デスティネーションファイルネームは、リネームオペレーション又はハードリンク作成オペレーションを表すターゲットネームとして指定されるファイルネームである。ハードリンクとは、ボリューム上の同一の物理ビットが２つ以上のファイルネームを有する場合において、ファイルネームをエイリアシング（aliasing）することをいう。ボリューム上の同一の物理ビットに該当する幾つかのファイルネームは、それぞれハードリンクと呼ばれる。デスティネーションファイルネームは、リネーム又はハードリンクパラメータに従って、ファイルネームプロバイダによって生成される。一実施形態においては、このデスティネーションファイルネームは、２つのフォーマット、すなわちノーマライズドフォーマットか、オープンドフォーマットのうちの一方で提供することができる。本実施形態においては、これらファイルネームのフラグメントは、必ずしも全てが、初期に、ファイルネームからパースされるわけではない。ボリュームと、シェアフラグメントとが、初期に、このファイルネームからパースされる。一度ＦＩＳを指し示すポインタがこのフィルタドライバに戻されると、このフィルタドライバは、さらに、最終コンポーネント、拡張子、ストリーム、及び親ディレクトリのフラグメントを、ファイルネームからパースするように要求することができる。

一実施形態においては、デスティネーションファイルネームはフィルタマネージャによって提供されたデータ構造内にキャッシュされない（例えば、パーストリームコンテキスト）。その代わりに、デスティネーションファイルネームは、フィルタマネージャのオペレーション特有のデータ構造内にキャッシュされる（例えば、IRP_CTRL）。デスティネーションファイルネームは、リネーム又はハードリンク作成オペレーション中にキャッシュされる。一度ネームコールバックが利用されると、本処理はブロック９０４に進む。

ブロック９０４において、このフィルタマネージャは、ファイルネームプロバイダからファイルネームを受け取るが、この受け取りは、ファイルネームプロバイダが、アルティチュードがこの要求元のフィルタドライバより低い別のフィルタドライバか、このファイルシステムかに関わらず、行なわれる。本処理はブロック９０５に進み、図７のプロセス７００に戻り、ブロック７０５に進む。

図１０は、本発明に従ってパフォームされるファイルネームキャッシュプロセスの例を示す流れ図である。プロセス１０００は、図７のプロセス７００がブロック７０５に進むとき、ブロック１００１から開始される。本処理は判定ブロック１００２に進む。

判定ブロック１００２において、このフィルタマネージャが、ネームプロバイダから受け取ったファイルネームに対して、リネームが現在行なわれているか否かが判定される。リネームとは、ファイルリネーム、ディレクトリリネーム、又はハードリンク作成オペレーションをいう。フィルタマネージャが受け取ったファイルネームに影響を与えるリネームが開始されると、ＦＩＳのキャッシングがサスペンド（suspend）され、このファイルネームに関係付けされているＦＩＳがキャッシュされないから、キャッシュの一部をパージ（purge）することができる。仮にリネーム中である場合には、本処理はブロック１００９に進み、ブロック１００９にて、このＦＩＳはキャッシュされず、本処理はブロック１０１０に進む。

しかしながら、仮にリネーム中でない場合には、本処理はブロック１００３に進み、特定のファイルネームのために作成されたＦＩＳに関係付けされているタイムスタンプ（ＴＳ）が、フィルタマネージャタイムスタンプ（ＦＴＳ）と比較される。このフィルタマネージャタイムスタンプは、最後のリネームプロシージャが完了したタイムに対応する。仮にＦＩＳが作成された後か、又は作成された時に、リネームが完了した場合（例えば、ＦＴＳ≧ＴＳ）には、このＦＩＳは、さらにファイルネームをケリーするためには、有効でない。しかしながら、仮にフィルタマネージャタイムスタンプがＦＩＳのタイプスタンプ未満である場合（例えば、ＦＴＳ＜ＴＳ）には、このＦＩＳは、さらにケリーするために、有効である。本処理は判定ブロック１００４に進む。

判定ブロック１００４においては、比較の結果に従って、ＦＩＳのタイムスタンプが、フィルタマネージャタイムスタンプ（ＦＴＳ）がＦＩＳのタイムスタンプ（ＴＳ）よりも少ないことを示すか否かが判定される。タイムスタンプが、ＦＩＳが今後のケリーに有効でないことを示す場合、プロセスはブロック１００９に続き、ＦＩＳはキャッシュされずに、本処理はブロック１０１０に進む。

しかし、タイムスタンプが、ＦＩＳが今後のケリーに有効であることを示す場合、本処理は判定ブロック１００５に進む。

判定ブロック１００５においては、ファイルに関係付けされているファイルネームの数が判定される。前述したように、ボリュームにストアされたファイルは、それぞれファイルに関係付けされている一意のファイルネームを表す複数のハードリンクとすることができる。したがって、仮にハードリンクの数が１を超える場合には、ファイルは１を超える数のファイルネームを有する。特定のファイルに関係付けされているファイルネームの数が１を超えないときは、本処理は判定ブロック１００６に進む。しかし、特定のファイル数に関係付けされているファイルネームの数が１を超える場合には、本処理はブロック１００８に進む。

判定ブロック１００６において、このフィルタマネージャがファイルネームプロバイダから受け取ったたファイルネームがノーマライズドフォーマットか否かが判定される。このフィルタマネージャに戻されたファイルネームがノーマライズドフォーマットであるときは、本処理はブロック１００７に進む。しかし、フィルタマネージャに戻されたファイルネームが、別のフォーマット、例えばショートファイルネーム又はオープンドファイルネームであるときは、本処理はブロック１００６に進む。

ブロック１００７において、このフィルタマネージャが受け取ったファイルネームに関係付けされているＦＩＳは、ストリームレベルでキャッシュされる。ストリームレベルでキャッシュされたＦＩＳにより、ＦＩＳを指し示すポインタを、特定のストリームに対応するファイルネームを要求する任意のフィルタドライバに戻すことができる。したがって、必要とする構造は少ない。というのは、特定のＦＩＳを、同一のストリームをシェアする複数のファイルオブジェクトのために、使用することができるからである。必要な構造が少なくなる。本処理はブロック１０１０に進み、ブロック１０１０にて、本処理は図７のプロセス７００に戻り、ブロック７０６に進む。

ブロック１００８において、このファイルマネージャが受け取ったファイルネームに関係付けされているＦＩＳは、ファイルオブジェクトレベルでキャッシュされる。ファイルオブジェクトレベルでキャッシュされたＦＩＳは、ファイルの特定のオープンインスタンスに適用される。ファイルオブジェクトレベルでキャッシュされたＦＩＳは、特定のファイルオブジェクトに対応する。たとえ特定のファイルオブジェクトが同一のストリームを第２ファイルオブジェクトとシェアできる場合であっても、このファイルオブジェクトレベルでストアされたＦＩＳは、特定のファイルオブジェクトに適用されるが、第２ファイルオブジェクトには適用されない。本処理はブロック１０１０に進み、ブロック１０１０にて、本処理は図７の処理７００に戻り、ブロック７０６に進む。

一実施形態においては、このＦＩＳがもはや有効でないときには、このＦＩＳに関係付けされているメモリ空間は割り振られない。このメモリ空間を解放する前に、このフィルタマネージャはこのＦＩＳに関係付けされている参照カウントを試験する。特定のＦＩＳに関係付けされたメモリは、参照カウントがゼロに達するまでは、解放されない。

リネーム
図１１は、本発明に従ってパフォームされるリネームプロセスの例を示す流れ図である。プロセス１１００は、リネームオペレーションが開始されるブロック１１０１から開始される。本処理は判定ブロック１１０２に進む。

判定ブロック１１０２において、現在のリネームプロセスがディレクトリのリネームであるか否かを判定する。ファイルネームのリネームに比べて、ディレクトリリネームにおいては、ディレクトリに関係付けされた全てのファイルのファイルネームが変更される。仮に現在のリネームプロセスがディレクトリのリネームを含まない場合には、本処理は判定ブロック１１０４に進む。しかし、仮に現在のリネームプロセスがディレクトリのネームを変更している場合には、本処理はブロック１１０３に進む。

ブロック１１０３において、ディレクトリネームの変更に応答して、当該ディレクトリに関係付けされているキャッシュが、フィルタマネージャと共にパージされる。キャッシュを参照するとき、このキャッシュには、特定のファイルネームのそれぞれのフォーマット（例えば、ノーマライズド、オープンド、ショート）に対するＦＩＳがそれぞれ含まれる。一実施形態においては、当該ディレクトリに関係付けされたキャッシュをパージするのは、ディレクトリリネームを反映するために、当該キャッシュを更新するのに利用されることになるであろうストリング比較よりも、効率的である。キャッシュをパージすることにより、その後に生成されるファイルネームが、ディレクトリのネーム変更を正確に反映できることを保証する。そして、これらフィルタドライバが、このフィルタマネージャに、新しいディレクトリネームを含むファイルネームをケリーするとき、当該キャッシュはリポピュレート（repopulate）される。本処理はブロック１１０７に進み、このプロセスは終了する。

判定ブロック１１０４において、現在のリネームプロセスが、ハードリンク作成オペレーションに対応するか否かが判定される。ハードリンクが作成されると、このハードリンクは、ストリームレベルのファイルネームに影響を及ぼす。言い換えると、ストリームレベルでキャッシュされているＦＩＳは、このハードリンクが作成されたとき、当該ファイルの全てのオープンインスタンスに対しては、最早、有効ではない。仮にリネームプロセスがハードリンク作成オペレーションに対応する場合には、本処理はブロック１１０５に進む。

ブロック１１０５において、ハードリンク作成オペレーションに関係付けされたキャッシュが、ストリームレベルでパージされる。このハードリンクに従うファイルネームに対応しているＦＩＳは、ストリームレベルでは、最早、ストアされず（仮に、元々、ストリームレベルでストアされている場合には、図１０を参照）、ファイルオブジェクトレベルでストアされる。複数のハードリンクを有するファイルに関係付けされているＦＩＳは、ファイルの特定のオープンインスタンスにとっては有効であるが、ファイルの全てのオープンインスタンスにとって有効ではない。本処理はブロック１１０７に進み、本プロセスは終了する。

あるいはまた、仮にリネームプロセスがディレクトリリネーム又はハードリンク作成オペレーションに対応していない場合には、本処理はブロック１１０６に進む。

ブロック１１０６において、特定のファイルネームに関係付けされているキャッシュが、ストリームレベルとファイルオブジェクトレベルの両方でパージされる。したがって、ファイルネームの各フォーマットについてそれぞれのＦＩＳが、フィルタマネージャに関係付けされたデータ構造（図４及び５を参照）から削除される。本処理はブロック１１０７に続き、プロセスは終了する。

ファイルネームトンネリング
一実施形態においては、本発明には、ファイルシステムのファイルネームトンネリング機能を補償する機能が含まれる。ファイルネームトンネリングには、ファイルシステム内にストアされたファイルネームに含まれたロングネーム／ショートネームのペアが関係する。トンネリングは、オペレーティングシステムによってサポートされ、その結果として、ファイルシステムの任意のリード／ライトでトンネリング機能を利用することができる。ファイルネームトンネリングは、ロングネーム又はショートネームのいずれかが削除されたときに生じるが、ある時間間隔で、再び作成される。ファイルネームトンネリング機能により、ファイルのメタ情報（meta-info）を短い期間に持続できるファイルシステムを当てにするプログラムと互換性を有することができる。このファイルトンネリングは、削除又はリネームの後に生じ、新しいディレクトリエントリにメタ情報を再導入した後に生じる（仮に作成又はリネームがあって、当該ネームのファイルが短期間で再び現れる場合）。ネームがディレクトリから除去されると（リネーム又は削除）、そのショートネーム／ロングネームのペアと、他の属性、例えば作成時間がキャッシュにセーブされ、除去されたネームによってキー（key）される。ネームがディレクトリに追加されると（リネーム又は作成）、リストア（restore）するための情報があるか否かをみるため、当該キャッシュがサーチされる。

図１２は、本発明に従ってパフォームされるファイルネームトンネリングプロセスであって、図７のプロセス７００と並行してランされるものを示す流れ図である。プロセス１２００はブロック１２０１から開始される。本処理は判定ブロック１２０２に進む。

判定ブロック１２０２において、この要求元フィルタドライバは、要求しているファイルネームがファイルネームトンネリングの候補であるか否かを認識する。ファイルネームトンネリングの候補は、８．３フォーマットの部分を含むファイルである。ファイルネームトンネリングは、ショートネーム（すなわち８．３フォーマットのファイルネーム）がファイルネームのノーマライズドバージョンに拡張されるとき、ファイルネームのノーマライズドバージョンに影響を及ぼす。ファイルに関係付けされているショートファイルネームを変更すると、これに従って、ノーマライズドネームも変更される。同様にして、ショートファイルネームが変更されない場合には、ノーマライズドファイルネームも変更されない。仮に当該ファイルネームがトンネリング候補でない場合には、本処理はブロック１２０５に進み、ファイルネームのCREATEオペレーションが正しく（successfully）完了し、ファイルネームに対応するＦＩＳがキャッシュされる。しかし、仮にファイルネームがトンネリング候補である場合には、本処理は判定ブロック１２０３に進む。

判定ブロック１２０３において、ファイルネーム候補であるファイルネームに対してトンネリングが生じたか否かが判定される。トンネリングが生じていない場合には、本処理はブロック１２０５に進み、ファイルネームのためのCREATEオペレーションが正しく完了すると、ファイルネームに対応するＦＩＳがキャッシュされる。しかし、仮にファイルネーム作成中にファイルネームトンネリングが使用された場合には、本処理はブロック１２０４に進む。

ブロック１２０４において、作成されたファイルネームに関係付けされているＦＩＳは、フィルタマネージャによって提供されたデータ構造内にキャッシュされない。本処理はブロック１２０６に進み、本プロセスが終了する。

本明細書、例、及びデータにおいては、本発明のコンポーネントを製造し使用することを完全に説明するものである。本発明の多くの実施形態は、本発明の精神及び範囲を逸脱することなく実施できるから、本発明は、添付の特許請求の範囲を逸脱するものではない。

本発明の一実施形態において使用することができるコンピューティング装置の例を示す図である。 本発明を実施するための環境の例を示すブロック図である。 本発明に係るＮＴＦＳファイルシステムのデータ構造を示すブロック図である。 本発明に係るファイルオブジェクトとファイルマネージャデータ構造との間の関係を示すブロック図である。 本発明に係るフィルタマネージャに関係付けされた他のデータ構造を示すブロック図である。 本発明に従ってラベル付けされたフラグメントを有するファイルネームの例を示す図である。 本発明に従ってパフォームされるファイルネームケリープロセスの例を示す流れ図である。 本発明に従ってパフォームされるファイルネーム要求処理プロセスの例を示す流れ図である。 本発明に従ってパフォームされるファイルネーム生成プロセスの例を示す流れ図である。 本発明に従ってパフォームされるファイルネーム情報構造キャッシュプロセスの例を示す流れ図である。 本発明に従ってパフォームされるリネームプロセスの例を示す流れ図である。 本発明に従ってパフォームされるファイルネームトンネリングプロセスの例を示す流れ図である。

符号の説明

１００ コンピューティング装置
１０２ プロセシングユニット
１０４ システムメモリ
１０５ オペレーティングシステム
１０６ プログラムモジュール
１０７ プログラムデータ
１０９ リムーバブルストレージ
１１０ ノンリムーバブルストレージ
１１２ 入力装置
１１４ 出力装置
１１６ 通信コネクション
１１８ 他のコンピューティング装置
１２０ フィルタマネージャ

Claims (21)

1. コンピューティング装置に実装されるファイルシステム環境において、フィルタマネージャによって、ファイルシステムフィルタドライバのためのファイルネームを管理する方法であって、該方法は、前記コンピューティング装置のメモリに格納された命令を前記コンピューティング装置が処理することによって実行され、
   前記フィルタマネージャが、アプリケーションから入力出力要求を受信するステップと、
   前記フィルタマネージャが、前記フィルタマネージャが前記入力出力要求を受信したことを示す通知を、第１フィルタドライバへ送信するステップと、
   前記フィルタマネージャが、指定されたフォーマットのファイルネームに対するファイルネーム要求を前記第１フィルタドライバから受け取るステップと、
   前記フィルタマネージャが、前記ファイルネーム要求に対応するファイルネームを受け取るために、ファイルネームを提供するファイルネームプロバイダをコールするステップと、
   前記ファイルネーム要求に対応する、データ構造であるファイルネーム情報構造を、前記ファイルネームプロバイダによって提供されたファイルネームに基づいて突き止めるステップと、
   前記突き止められた、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造を、前記フィルタマネージャのデータ構造内にキャッシュするステップと、
   前記フィルタマネージャが、前記突き止められたファイルネーム情報構造を指し示すポインタを前記第１フィルタドライバに戻すステップと
   を備えたことを特徴とする方法。
2. 請求項１において、前記ファイルネームプロバイダをコールする前に、前記フィルタマネージャが、前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定するステップをさらに備えたことを特徴とする方法。
3. 請求項１において、前記ポインタを前記第１フィルタドライバに戻すステップの後に、前記突き止められたファイルネーム情報構造に関係付けされている参照カウントを更新して、前記突き止められたファイルネーム情報構造を前記フィルタマネージャのデータ構造内に維持されるようにするステップであって、前記参照カウントは前記ファイルネーム情報構造が有効であることを示すステップをさらに備えたことを特徴とする方法。
4. 請求項１において、前記突き止められたファイル情報構造をキャッシュする前に前記ファイルネーム情報構造が有効か否かを判定されるようにするため、前記ポインタが前記第１フィルタドライバに戻されたとき、前記突き止められたファイルネーム情報構造に関係付けされているタイムスタンプを更新するステップをさらに備えたことを特徴とする方法。
5. 請求項１において、前記ファイルネーム要求を受け取るステップは、前記第１フィルタドライバの識別子を指定するファイルネーム要求と、前記ファイルネームによって識別されたファイルのオープンインスタンスに対応するファイルオブジェクトと、前記ファイルネームのフォーマットとを受け取るステップをさらに備えたことを特徴とする方法。
6. 請求項５において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、及びショートのうちの少なくとも１つを備えたことを特徴とする方法。
7. 請求項１において、前記ファイルネームプロバイダをコールするステップは、第２のフィルタドライバが前記ファイルネームプロバイダとしてオペレートしているとき、アルティチュードの低い第２のフィルタドライバを、前記第１フィルタドライバからコールするステップをさらに備えたことを特徴とする方法。
8. 請求項１において、前記ファイルネーム情報構造をキャッシュするステップは、
   前記フィルタマネージャが、リネームが進行中であるか否かを判定するステップと、
   前記リネームによって前記ファイルネームの少なくとも一部分が変更されるとき、キャッシュされたファイルネーム情報構造の適正な部分をパージするステップと
   をさらに備えたことを特徴とする方法。
9. 請求項１において、前記突き止められたファイルネーム情報構造は、ストリームレベル及びファイルオブジェクトレベルのうちの一方のレベルで、前記フィルタマネージャのデータ構造内にキャッシュされることを特徴とする方法。
10. 請求項１において、前記ファイルネーム情報構造をキャッシュするステップは、
    前記フィルタマネージャが、リネームが進行中であるか否かを判定するステップと、
    前記リネームが終了したタイムと、前記突き止められたファイルネーム情報構造が作成されたタイムとを比較するステップと、
    前記突き止められたファイルネーム情報構造が作成されたタイムと比較した結果、前記リネームが終了したタイムの方が遅い場合に、前記ポインタを前記第１フィルタドライバに戻さないようにするステップと
    をさらに備えたことを特徴とする方法。
11. コンピュータ実行可能なコンポーネントを有するコンピュータ可読媒体であって、
    コンピューティング装置に実装されるファイルシステム環境において、ファイルシステムのための第１フィルタドライバにより行なわれるファイルネーム要求を管理するフィルタマネージャを備え、
    前記フィルタマネージャは、
    アプリケーションから入力出力要求を受け取り、
    前記入力出力要求を受け取ったことを示す通知を前記第１フィルタドライバへ送信し、
    指定されたフォーマットを有するファイルネームに対するファイルネーム要求を、前記第１フィルタドライバから受け取り、
    前記ファイルネーム要求を満たすデータ構造であるファイルネーム情報構造が予めキャッシュされているか否かを判定し、前記ファイルネーム情報構造が予めキャッシュされている場合に、前記ファイルネーム情報構造を指し示すポインタを前記フィルタドライバに戻し、
    前記ファイルネーム情報構造が予めキャッシュされていない場合に、
    前記ファイルネーム要求に対応するファイルネームを受け取るために、ファイルネームを提供するファイルネームプロバイダをコールし、
    前記ファイルネーム要求に対応するファイルネーム情報構造を、前記ファイルネームプロバイダによって提供されたファイルネームに基づいて突き止め、
    前記突き止められたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造を、前記フィルタマネージャのデータ構造内にキャッシュし、
    前記突き止められたファイルネーム情報構造を指し示すポインタを前記第１フィルタドライバに戻す
    ように構成されたことを特徴とするコンピュータ可読媒体。
12. 請求項１１において、前記フィルタマネージャは、前記第１フィルタドライバによるファイルネーム要求に加えて、前記ファイルシステムのための入力出力要求を、前記フィルタマネージャが受け取って処理するようにするため、前記ファイルシステムと、オペレーティングシステムに関係付けされている前記アプリケーションとの間に配置されたことを特徴とするコンピュータ可読媒体。
13. 請求項１１において、前記フィルタマネージャは、ファイルネーム情報構造がキャッシュされるファイルネームキャッシュデータ構造を含み、
    前記ファイルネームキャッシュデータ構造は、前記ファイルネーム情報構造に対応する前記ファイルネームのフォーマットに従って編成される
    ことを特徴とするコンピュータ可読媒体。
14. 請求項１１において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、又はショートのうちの少なくとも１つであることを特徴とするコンピュータ可読媒体。
15. コンピューティング装置に実装されるファイルシステム環境において、フィルタマネージャによって、ファイルシステムフィルタドライバのためのファイルネームを管理するためのコンピュータ実行可能命令を有するコンピュータ可読媒体であって、前記コンピュータ実行可能命令がコンピュータによって処理されると実行される方法は、
    前記フィルタマネージャが、アプリケーションから入力出力要求を受信するステップと、
    前記フィルタマネージャが、前記フィルタマネージャが前記入力出力要求を受信したことを示す通知を、第１フィルタドライバへ送信するステップと、
    前記フィルタマネージャが、指定されたフォーマットのファイルネームに対するファイルネーム要求を、前記第１フィルタドライバから受け取るステップと、
    前記フィルタマネージャが、前記ファイルネーム要求を満たすデータ構造であるファイルネーム情報構造が予めキャッシュされているか否かを判定し、前記ファイルネーム情報構造が予めキャッシュされている場合に、前記ファイルネーム情報構造を指し示すポインタを前記フィルタドライバに戻すステップと、
    前記ファイルネーム情報構造が予めキャッシュされていない場合には、
    前記ファイルネーム要求に対応するファイルネームを受け取るために、ファイルネームを提供するファイルネームプロバイダをコールするステップと、
    前記ファイルネーム要求に対応するファイルネーム情報構造を、前記ファイルネームプロバイダによって提供されたファイルネームに基づいて突き止めるステップと、
    前記突き止められたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造を、前記フィルタマネージャのデータ構造内にキャッシュするステップと、
    前記突き止められたファイルネーム情報構造を指し示すポインタを、前記第１フィルタドライバに戻すステップと
    を備えたことを特徴とするコンピュータ可読媒体。
16. 請求項１５において、前記ポインタを前記第１フィルタドライバに戻すステップの後に、前記突き止められたファイルネーム情報構造を前記フィルタマネージャのデータ構造内に維持されるようにするため、前記突き止められたファイルネーム情報構造に関係付けされている参照カウントを更新するステップであって、前記参照カウントは前記ファイルネーム情報構造が有効であることを示すステップをさらに備えたことを特徴とするコンピュータ可読媒体。
17. 請求項１５において、前記突き止められたファイル情報構造をキャッシュする前に、前記ファイルネーム情報構造が有効か否かを判定するようにするため、前記ポインタが前記第１フィルタドライバに戻されるとき、前記突き止められたファイルネーム情報構造に関係付けされているタイムスタンプを更新するステップをさらに備えたことを特徴とするコンピュータ可読媒体。
18. 請求項１５において、前記ファイルネーム要求を受け取るステップは、前記第１フィルタドライバの識別子を指定するファイルネーム要求と、前記ファイルネームによって識別されたファイルのオープンインスタンスに対応するファイルオブジェクトと、前記ファイルネームのフォーマットとを受け取ることを特徴とするコンピュータ可読媒体。
19. 請求項１８において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、及びショートのうちの少なくとも１つを含むことを特徴とするコンピュータ可読媒体。
20. 請求項１５において、前記ファイルネーム情報構造をキャッシュするステップは、
    前記フィルタマネージャが、リネームが進行中であるか否かを判定するステップと、
    前記リネームによって前記ファイルネームのうちの少なくとも一部が変更される場合に、キャッシュされたファイルネーム情報構造の適正な部分をパージするステップと
    を備えたことを特徴とするコンピュータ可読媒体。
21. 請求項１５において、前記突き止められたファイルネーム情報構造は、ストリームレベル及びファイルオブジェクトレベルのうちの一方のレベルでキャッシュされることを特徴とするコンピュータ可読媒体。

Images