JP2004038960A - ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法 - Google Patents
ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法 Download PDFInfo
- Publication number
- JP2004038960A JP2004038960A JP2003172376A JP2003172376A JP2004038960A JP 2004038960 A JP2004038960 A JP 2004038960A JP 2003172376 A JP2003172376 A JP 2003172376A JP 2003172376 A JP2003172376 A JP 2003172376A JP 2004038960 A JP2004038960 A JP 2004038960A
- Authority
- JP
- Japan
- Prior art keywords
- file name
- file
- information structure
- filter driver
- name information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
【解決手段】フィルタマネージャは、要求されたファイルネームのタイプに対応するファイルネーム情報構造を指し示すポインタを、要求元のフィルタドライバに戻す。フィルタマネージャは、種々のフィルタドライバ間でシェアできる情報を含むファイルネーム情報構造のキャッシュを管理し、フィルタドライバのファイルネームケリーを譲渡する。フィルタマネージャのキャッシュ機能は、効率を上げるものであり、ファイルネームの所望の部分を検索するためファイルシステムフィルタドライバが必要とするファイルネームオペレーションの数を減少させて、ファイルシステム内のファイルネームケリーのオーバヘッドを減少させる。
【選択図】 図1
Description
【0001】
本発明は、ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法に関する。
【背景技術】
【0002】
ファイルシステムドライバ(FSD)は、ファイルシステムフォーマットを管理する。FSDは、カーネルモードでラン(run)するが、標準のカーネルモードドライバとは多くの点で異なっている。最も重要なのは、FSD自体が、それぞれオペレーティングシステムによりファイルシステムドライバとして登録されることである。ファイルシステムドライバより上のレイヤーにあるフィルタドライバは、ファイルシステムフィルタドライバという。ファイルシステムフィルタドライバには、ファイルシステム要求をビュー(view)し、その要求を、オプションで、修正するか処理する(complete)能力が含まれる。ファイルシステムフィルタドライバには、暗号化、ウィルス検出、及び他のオペレーションをパフォームするフィルタドライバを含めることができる。
【0003】
一般に、ファイルシステムフィルタドライバをインプリメントするコードは、大部分が、ファイルネーム検索とフォーマットとで占められる。ファイルシステム(例えば、NTFS、FAT等)によって、許容されるファイルネームのサイズを変えることができる。例えば、NTFSは、ファイルネームパスにある各コンポーネントが255キャラクタに限定され、合計のファイルネームの長さが65536キャラクタに限定されるように、ネームスペシフィケーション(namespecification)を設定する。ファイルネームには、Unicodeキャラクタを含めることができ、同様に、複数のピリオドと、埋込みスペース(embededspace)とを含めることができる。しかし、あるファイルシステムは、ファイルネームが8キャラクタ(非Unicode)に限定され、ファイルネームの後に、ピリオドと、3キャラクタの拡張子とが来るようになっており、これは一般に「8.3」フォーマットと呼ばれている。そこで、元々これらのファイルシステムためにライト(write)されたアプリケーションにおいても、8.3フォーマットか、又はこれと互換性のあるファイルネームを理解するできるようになっている。NTFSのような他のファイルシステムにおいては、アプリケーションによりショートネーム(shortname)が要求されたとき、当該ファイルシステムは、ロングネーム(longname)で作成されたファイルに代えて、8.3フォーマットのショートネームを生成する。ロングネームは、8.3フォーマットよりも長いファイルネームと、Unicodeキャラクタを含むファイルネームと、複数のピリオドキャラクタ又は1つのビギニングピリオド(beginningperiod)を有するファイルネームと、埋込みスペースを有するファイルネームとに対応する。ショートネームは、ファイル用のフル機能(fullyfunctional)を有するエイリアス(alias)であり、ロングネームと同じディレクトリにストアされている。ロングネームもショートネームも、ファイルをオープンするか、リードするか、ライトするか、又はコピーするのに使用することができる。
【0004】
ファイルネーム用のフォーマットは他にも存在し、ファイルシステムフィルタドライバは、これらフォーマットのうちのいずれかのフォーマットのファイルネームのケリーを開始することができる。ファイルネームは、I/Oオペレーション時にどのアクションを行うべきかをコントロールするため、ファイルシステムフィルタドライバにより使用されるのが一般的である。ユーザ又はアプリケーションは、ファイルネームを、多くの異なるフォーマットのうちの1つで、指定することができる。ファイルシステムフィルタドライバにおいては、当該ファイルネームがそのオペレーションに関係しているか否かを試験するため、当該ファイルネームを標準フォーマットにノーマライズ(normalize)することもある。ファイルシステムフィルタドライバは、一般に、ファイルネームをパース(parse)してフラグメント(fragment)にする。例えば、ウィルスを検出できるファイルシステムフィルタドライバは、ファイルネームの拡張子のタイプ(例えば、.exe、.dll等)に最も関心を持ち、ファイルネームから拡張子をパースしようとする。現在では、複数のフィルタドライバが、それぞれ、自分に、1つのFSDにアタッチ(attach)することができるが、各フィルタドライバが、当該FSSに対してファイルネームをケリーするから、リソースを消費(consume)する。各ファイルシステムフィルタドライバには、コードが含まれ、これらファイルシステムフィルタドライバは、ファイルネームを管理し操作するため、プロセスタイム(processtime)をファイルネームの管理及び操作に当てる。
【考案の開示】
【課題を解決するための手段】
【0005】
本発明によれば、ファイルシステムフィルタドライバ(以下「フィルタドライバ」という。)用のファイルネームオペレーションを処理し、償却する(amortize)ためのファイルシステムフィルタマネージャ(以下「フィルタマネージャ」という。)を含む。フィルタマネージャは、各フィルタドライバに共通のファイルネームの検索及びフォーマット化機能を提供する。さらにフィルタマネージャは、1つ以上のフィルタドライバでシェアできるネーム情報のキャッシュを提供する。キャッシュ、ファイルネーム検索、及びフォーマット化機能は、フィルタマネージャ内でのファイルネーム管理を統合することによって、ファイルシステム内でのファイルネーム管理の効率を上げるものである。
【0006】
本発明は、ファイルシステム内のフィルタドライバ用のファイルネームを管理する。本発明は、フィルタドライバからのファイルネームケリーを処理するフィルタマネージャを含む。フィルタマネージャは、ドライバスタック内のフィルタドライバからのファイルネーム要求を受け取って処理する。フィルタマネージャは、前に生成されたファイルネームに関するファイルネーム情報構造のキャッシュを維持する。各ファイルネーム情報構造は、ファイルネームのフラグメントを指し示すポインタを含むポインタリストを備えている。フィルタマネージャは、第一に、フィルタドライバによるファイルネーム要求に対応するファイルネーム情報構造が前に生成されたか否かを判定するため、キャッシュを試験する。このようなファイルネーム情報構造が存在しない場合には、フィルタマネージャは、そのファイルネームのファイルネームプロバイダをコールする。ファイルネーム情報構造が作成されていた場合には、フィルタマネージャは、ファイルネーム情報構造に関係付けされている参照カウント及びタイムスタンプを更新する。参照カウントは、ファイルネーム情報構造が少なくとも1つのフィルタドライバによって使用されている限り、ファイルネーム情報構造が有効であることを保証するものである。タイムスタンプは、ファイルがリネーム(rename)されるとき、又はその後のオペレーションがファイルネームに影響を与えるとき、ファイルネーム情報構造が、ファイル用の現在のファイルネームを反映することを保証するものである。ついで、フィルタマネージャは、対応するファイルネーム情報構造を指し示すポインタを、要求側フィルタドライバに戻す。
【発明を実施するための最良の形態】
【0007】
簡潔に言えば、本発明は、ファイルシステムにおいて、フィルタドライバ用のファイルネームを管理する方法及びシステムに関する。本発明には、フィルタドライバからのファイルネームケリーをハンドル(handle)するフィルタマネージャが含まれる。フィルタマネージャは、要求されたファイルネームのタイプに対応するファイルネーム情報構造を指し示すポインタを、要求側フィルタドライバに戻す。このフィルタマネージャは、次のようなファイルネーム情報構造のキャッシュも管理し、フィルタドライバに対して行うファイルネームケリーを償却する(amortize)。このファイルネーム情報構造には、種々のフィルタドライバでシェア(share)できる情報が含まれる。このフィルタマネージャにキャッシュ機能があるので、ファイルシステムフィルタドライバがファイルネームの所望の部分を取り出すのに要求されるファイルネームオペレーションの数が減少し、これにより、効率が良くなり、ファイルシステム内でのファイルネームケリーのオーバヘッドが減少する。
【0008】
本明細書及び特許請求の範囲においては、当該コンテキストが明確にそうでないと述べない限り、次の用語は、本明細書に明示的に関係付けをした意味を有するものとする。
【0009】
「FIS(FileInformationStructure)」とは、フィルタマネージャに関係付けをしたデータ構造であって、少なくとも一実施形態においては、ボリューム(volume)にストアされた特定のファイルネームのネームフラグメント(namefragment)を指し示すポインタをストアするデータ構造をいう。「ネームフラグメント」とは、ファイルネームの一部をいう。例えば、ファイルネームには、拡張子(例えば、.txt、.dll、.docなど)が含まれるのが典型的である。この拡張子は、ネームフラグメントの1つのタイプを表す。
【0010】
「アルティチュード(altitude)」とは、特定のフィルタドライバが、アプリケーションと、ボリュームを管理するファイルシステムとの間で送信されるIRP(Input/OutputRequestPacket)に応答する順番(order)をいう。当該ファイルシステムにおいて、他のフィルタドライバよりアルティチュードの高いフィルタドライバは、「furtheraway」といわれ、当該IRPがアプリケーションから送信されるとき、IRPに関係付けされたオペレーションを、これら他のフィルタドライバより早くハンドルする。これに対して、当該IRPがファイルシステムから送信されるとき、IRPに関係付けされたオペレーションを、他のフィルタドライバより遅く処理する場合、当該フィルタドライバのアルティチュードは低い。これらIRPとは、多くの場合、IOサブシステムにおいて使用されるデータ構造をいうが、これらにはNTFSのようなファイルシステムが含まれる。しかしながら、たとえIRPのみを参照できるとしても、当然、本発明に係るフィルタマネージャは、当該IRPを、別のデータ構造、例えば、所定のオペレーションをフィルタに提示するためのCallbackData構造に、変換することができる。
【0011】
「ファイルネームプロバイダ」とは、ファイルシステムか、又はファイルに代替のファイルネームを提供するために登録された特定のフィルタドライバか、のいずれかをいう。
【0012】
オペレーティング環境の例
図1を説明する。本発明をインプリメントしたシステムの例には、コンピューティング装置100のようなコンピューティング装置が含まれる。非常に基本的な構成においては、コンピューティング装置100には、少なくとも1つのプロセシングユニット102と、システムメモリ104とが含まれるのが典型的である。正確な構成と、コンピューティング装置のタイプとに応じて、システムメモリ104は、(RAMのような)揮発性メモリか、(ROM、フラッシュメモリのような)不揮発性メモリか、又はこれらメモリを組み合わせたものとすることができる。システムメモリ104には、オペレーティングシステム105と、1つ以上のプログラムモジュール106と、プログラムデータ107とが含まれるのが典型的である。さらに、オペレーティングシステム105には、本発明に係るフィルタマネージャ120を含めることができる。この基本的な構成は、図1において、破線108内のコンポーネントで図示してある。
【0013】
コンピューティング装置100は、フィーチャ(feature)又は機能を追加することができる。例えば、コンピューティング装置100には、追加の(リムーバブル及び/又はノンリムーバブル)データストレージ装置、例えば、磁気ディスク、光ディスク、又はテープを含めることもできる。このような追加のストレージ装置としては、図1において、リムーバブルストレージ109と、ノンリムーバブルストレージ110が図示してある。コンピュータ記憶媒体には、揮発性及び不揮発性、リムーバブル及びノンリムーバブルの媒体であって、情報を記憶するための方法又は技術、例えば、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータを、インプリメントした媒体を含めることができる。システムメモリ104、リムーバブルストレージ109、及びノンリムーバブルストレージ110は、全て、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、RAM、ROM、EEPROM、フラッシュメモリその他のメモリ技術か、CD−ROM、DVD(digitalversatiledisk)その他の光記憶装置か、磁気カセット、磁気テープ、磁気ディスク記憶装置その他の磁気記憶装置か、あるいは、所望の情報をストアするために使用可能な媒体であってコンピューティング装置100がアクセス可能な他の媒体が含まれるが、これらに限定されるものではない。このようなコンピュータ記憶媒体は、コンピューティング装置100の一部とすることができる。コンピューティング装置100は、入力装置112、例えばキーボード、マウス、ペン、音声入力装置、タッチ入力装置を有することができる。出力装置114、例えばディスプレイ、スピーカ、プリンタも含めることができる。これらの装置は、当分野で周知のものであるから、ここでは詳細に述べない。
【0014】
コンピューティング装置100は、通信コネクション116も含むことができ、これにより、他のコンピューティング装置118と、例えばネットワークを介して、通信することができる。通信コネクション116は、通信媒体の一例である。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又は変調データ信号、例えば、搬送波その他のトランスポートメカニズム上の他のデータにより具現化できるのが典型的であり、この通信媒体には、情報配信媒体(informationdeliverymedia)が含まれる。「変調データ信号」とは、情報をエンコードして信号中に入れて設定(set)するか変化させた1つ以上の特性を有する信号をいう。例えば、通信媒体には、ワイヤード(wired)媒体、例えば、ワイヤード(wired)ネットワーク又はダイレクトワイヤード接続と、ワイヤレス(wireless)媒体、例えば、音波、RF、赤外線等が含まれるが、これらに限定されるものではない。本明細書において使用されるコンピュータ可読媒体という用語には、記憶媒体と、通信媒体とが含まれる。
【0015】
フィルタドライバ構造とファイルシステム
図2は、本発明を実施するための環境例を示すブロック図である。図2に示す環境は、ファイルシステムのためのIO(Input/Output)サブシステム環境200であって、このIOサブシステム環境200には、本発明に係るフィルタマネージャ120が含まれる。
【0016】
ファイルシステム環境200には、ユーザモードでオペレートするアプリケーション202と、カーネルモードでオペレートするNTFSファイルシステム220とが含まれる。ここにおいては、NTFSのコンテキストで記載するが、当然、本発明は、他の多くのファイルシステム、例えばFAT、FAT32、EXT2、HPFS等に対しても等しく適用可能である。
【0017】
NTFS220とアプリケーション202との間に、カーネルモードでオペレートするフィルタドライバ構造210がある。フィルタドライバ構造210には、フィルタマネージャ120が含まれるとともに、複数のフィルタドライバ(例えば、212A〜C)からなるフィルタドライバスタックが含まれる。NTFS220は、ボリューム230にストアされたファイルシステム構造を管理するため、システムメモリ104内において、複数のデータ構造(例えば、240)を維持している。データ構造240については、以下に、図3を参照して詳細に述べる。ボリューム230には、ファイルレコードのアレイ(array)を提供するMFT(masterfiletable)232が含まれるが、このファイルレコードのアレイには、ボリューム230が有する各ファイルに対して1つのレコードが含まれ、レコードとしてはMFT232に対するレコードもある。例えば、MFT232には、ファイルネーム属性234のレコードを含めることができ、追加のファイルネーム属性234を含む他のファイルレコードを指し示すポインタを含めることができる。
【0018】
IOサブシステム環境200においては、フィルタドライバ212A〜Cにより、NTFSファイルシステム220に機能が追加される。前に述べたシステムにおいては、フィルタドライバ212A〜Cは、カーネルモードでオペレートしているNTFS220と、ユーザモードでオペレートしているアプリケーション202との間で送信さるIRPをインタセプト(intercept)する。例えば、アプリケーションは、ファイルを作成するためのファンクション(function)(例えば、CreateFile)をコールしてファイルにアクセスする。これに応答して、指定されたタイプのIRPが生成される。この生成されたIRPにより、オープンされているファイルのネームをストアするファイルオブジェクトが作成され、ついで、このIRPがフィルタ構造210に渡される。フィルタドライバ212A〜Cは、それぞれ、指定された機能をインプリメントするため、このIRPが参照するファイルネームをルックアップ(lookup)することができる。そして、ハンドルが、コーリングチェーン(callingchain)を介して戻され、戻りパラメータ(returnparameter)として、アプリケーション202に到達することになる。
【0019】
フィルタドライバの機能としては、フィルタドライバがIRPを受け取ったとき、IRPに関係付けされているファイルのファイルネームを知ったか否かに依存する機能がある。例えば、ウィルス検出用のフィルタドライバは、ファイルネーム中に「.exe」又は「.dll」の拡張子の付いたファイルに集中することができる。あるいはまた、暗号化向けのフィルタドライバは、特定パスのファイルの暗号化に集中することができる。このIRPには、このIRPに関係付けされているファイルのフル(full)ファイルネームが含まれていなくてもよい。例えば、アプリケーション202からのファンクションコールの、リード、ライト、又は作成においては、ファイルネームではないファイルIDを指定することができる。このファイルIDとは、ボリューム230が有するファイルを一意に識別する数字である。CREATE又はOPENオペレーションのために、ユーザがファイルを識別するのに使用するファイルネーム又はIDは、当該ファイルにとって、pre―CREATE期間の間、有効である。CREATE又はOPENオペレーションの後、ファイルオブジェクトには、NTFS220が、ファイルのファイルネームを使用せずに、どのファイルが参照されているかを識別できるデータ構造が、含まれる。したがって、仮にフィルタドライバ(例えば、212A〜C)が、pre―CREATE期間の後に、ファイルネームが必要な場合には、NTFS220にファイルネームをケリーする。フィルタドライバ212A〜Cは、オペレーションを完了させるため、NTFS220へのファイルネームのケリーを開始することを要求することができる。
【0020】
本発明においては、フィルタドライバスタック(すなわち、フィルタドライバ212A〜C)によりシリアルに渡されるIRPに代えて、当該IRPが、フィルタマネージャ120に直接渡される。ついで、フィルタマネージャ120は、各フィルタドライバ212A〜CにIRPを通知するから、当該IRPに関係する機能を含むフィルタドライバは、フィルタマネージャ120と(例えば、コールバックにより)、インタラクトすることができる。フィルタドライバ212A〜Cがフィルタマネージャ120とインタラクトできる1つの方法は、指定されたオペレーションを完了するため、フィルタマネージャ120に対してファイルネームをケリーしてインタラクトする方法である。フィルタマネージャ120は、フィルタドライバ212A〜Cによるファイルネームの要求を管理する。
【0021】
フィルタマネージャ120により、3つのフォーマット、すなわち、ノーマライズド(Normalized)、ショート(Short)、又はオープンド(Opened)のうちの1つのフォーマットで、ファイルネームをケリーすることができる。ノーマライズドファイルネームは、ショートネームが拡張されたものであり(すなわち、ノーマライズドファイルネームはロングネームである)、ディレクトリのルートからのファイルのフルパスを有するから、マウントポイントが解決(resolve)される(図10に関する説明を参照されたい)。オープンドファイルネームには、ファイルをオープンするために使用されたフォーマットのファイルネームが含まれる(例えば、ショートネーム又はロングネームのいずれかを含むことができる)。ショートファイルネームには、ファイルのフルパスの最終コンポーネントであって、8.3フォーマット(例えば、「filename.ext」)のファイルネームのみが含まれる。
【0022】
フィルタマネージャ120は、プロセス中の特定時間においては、あるファイルネームフォーマットをケリーすることができない。例えば、アプリケーション202によってファイル作成オペレーション(すなわち、ファイルオープンオペレーション)が開始されたときは、オペレーションがNTFS220に達するまでは、新しく作成されたファイルのファイルネームが有効であるか否かを判定することが、恐らく、不可能になる。この期間の間は、フィルタマネージャ120はショートファイルネームフォーマットで、ファイルネームをケリーすることはできない。これは、ショートファイルネームフォーマットの有効性(validity)が疑わしいからである。
【0023】
図3は、本発明に係るNTFSファイルシステムによって維持されるデータ構造240の例を示す。データ構造240には、ファイルオブジェクト310及び312と、ストリームコントロールブロック(SCB)320と、ファイルコントロールブロック(FCB)330とが含まれる。
【0024】
ファイルは、1つ以上のデータストリームにより構成され、そのうちの1次データストリームをネーム無し(unnamed)とすることができる。このファイルシステムは、SCB(例えば、322及び324)を使用して、ファイルの各データストリームを一意に識別する。例えば、SCB322は、ファイルオブジェクトのうちの1つのファイルオブジェクト(例えば、図3に310で示す)に対しては、1次のネーム無しストリームであり、SCB324は、このファイルオブジェクトに対しては2次のネーム付きストリームである。ファイルオブジェクト(310、312)は、ファイルの特定データストリーム(ネーム付き又はネーム無し)のオープンに対応する。このファイルシステムは、ファイルオブジェクト(310、312)から、MFT232によって提示されているボリュームが有するファイルのロケーションを指し示すポインタを幾つか作成する。ファイルオブジェクト310及び312は、それぞれオープンファイルの単一のインスタンスを表すものであるが、コール側アプリケーションがリード又はライトを試みているファイルに対応するSCB(streamcontrolblock)320を指し示している。特定のファイルに対するSCBは、共通のファイルコントロールブロック(例えば、330)を指し示している。FCB330には、MFT232のファイルのレコードを指し示すポインタが含まれる。
【0025】
図4は、ファィルオブジェクトと、本発明に係るフィルタマネージャデータ構造との間の関係を示す。図3に関して述べたように、ファイルオブジェクト320はファイルのオープンインスタンスを表す。あるタイプのドライバ、例えばフィルタドライバは、ファイルオブジェクト320内のフィールドのうちの幾つかを利用することができる。本発明は、ファイルオブジェクト320内のフィールドを、ポインタ用に使用している。ポインタ(PvoidFsContext)は、FsContext共通ヘッダ410というデータ構造であって、ロックと、パーストリームコンテキスト(perstreamcontext)のリンクされたリストとが含まれるデータ構造を指し示している。このFsContext共通ヘッダ410は、ファイルシステムが「パーストリームコンテキスト」機能をサポートするか否かを指定する。「パーストリームコンテキスト」とは、ファイルシステム(NTFSファイルシステムに存在するようなファイルシステム)により、他のドライバが幾つかの情報をこのストリームに関係付けすることができるか否かをいう。FsContext共通ヘッダ410は、フィルタドライバがポピュレート(populate)できるパーストリームコンテキストのリンクされたリストに、指定された機能のための情報を提供する。FsContext共通ヘッダ410は、ファイルシステムに応じて、ファイルコントロールブロック(FCB)又はストリームコントロールブロック(SCB)のいずれかとすることができる。本発明において、NTFSファイルシステムに関しては、FsContext共通ヘッダ410は、パーストリームコンテキストのリンクされたリストを含むSCBであって、コンテキストをファイルオブジェクト(例えば、320)に提供するためのものである。パーストリームコンテキスト412には、それぞれ、2つのキー(Key1、Key2)が含まれるとともに、フィルタマネージャによって維持されるフィルタマネージャデータ構造420を指し示すポインタ(pVoidFMDS)が含まれる(図2を参照)。フィルタマネージャデータ構造420は、フィルタドライバからの要求に応答して作成された各ファイルネームのためのFIS(filenameinformationstructure)(図5を参照)をストアするためのキャッシュである。各フィルタマネージャデータ構造420は、さらに、各FISに関係付けされたファイルネーム(例えばノーマライズドネーム、オープンドネーム、及びショートネーム)のフォーマットに従って、ネームキャッシュデータ構造422A〜Cに編成される。
【0026】
図5は、本発明に係るフィルタマネージャに関係付けされたデータ構造の例を示す。図4に示した各ネームキャッシュデータ構造422A〜Cには、ツリー構造が含まれる。一実施形態においては、ツリー構造はスプレイ(splay)ツリー構造である。スプレイツリーは、データベースにファイルを配置したり、データベースからファイルを突き止めたりすることに関連して共通に使用される。
【0027】
本発明においては、当該ツリー構造のノード510は、特定のFIS520を指し示すことができる。ノード510は、2つのキー(Key1、Key2)でインデックス付けされており、ノード510には、ファイルネームに対応する適正なFISを指し示すポインタ(pVoidFIS)が含まれる。図8に関連して説明するが、本発明においては、Key1は要求されたファイルネームのファイルオブジェクトに対応し、Key2はファイルネームのファイルネームプロバイダに対応する。
【0028】
FIS520には、プライベートヘッダ522と、ファイルネームポインタリスト524とが含まれる。特定ファイルネーム、すなわちノーマライズド、オープンド、又はショートに対して、異なるFIS520が可能である。言い換えれば、特定ファイル用のノーマライズドファイルネームと、これと同一のファイル用のショートファイルネームが、それぞれ異なるFIS520で表される。
【0029】
プライベートヘッダ522には、参照カウント、タイムスタンプ、その他のデータに関するデータが含まれる。この参照カウントは、FIS520が、フィルタドライバによって参照される限り、メモリに維持されることを保証する。このタイムスタンプは、ファイルがリネームされるか、又はリネーム後のオペレーションがファイルネームに影響を及ぼすとき、FIS520が当該ファイルに対して現在のファイルネームを反映させる、ことを保証する。このタイムスタンプについては、図10を参照して詳細に説明する。
【0030】
ファイルネームポインタリスト524には、単一のメモリバッファにある同一のファイルネームのうちの指定された複数のフラグメントをそれぞれ指し示すポインタが含まれる。各フラグメントは、当該ファイルネームの一部を構成するUnicodeストリングに対応する(図6を参照)。これらポインタは、ファイルネームを備えたキャラクタのアレイを示すインデックスとしてオペレートする。当該ファイルネームがフィルタマネージャによってパースされるから、当該ファイルネームのフラグメントを試験することを望むフィルタドライバは、当該ファイルネームを個々にパースする必要はない。
【0031】
図6は、本発明によりラベル付けされたフラグメントを有するファイルネームの例を示す。このインプリメンテーションにおいては、ファイルネーム600には、要求があれば提供することができるフィルタマネージャ(図2を参照)によって認識された6つのフラグメント(610、620、630、640、650、660)が含まれる。各フラグメントは、図5のファイルネームポインタリスト524にリストされているポインタのうちの1つによって、指し示されている。これらフラグメントには、ボリューム610、シェア(Share)620、親ディレクトリ630、最終コンポーネント640、拡張子650、及びストリーム660が含まれる。
【0032】
ボリューム610とは、当該ファイルネームのうち、当該ファイルをストアする論理ボリュームを記述した部分をいう。ネットワークからのファイルにおいて、ボリューム610とは、当該ファイルネームのうち、リモートファイルにアクセスするのに使用されるネットワークプロバイダを記述する部分をいう(例えば、\Device\LanmanRed\)。
【0033】
シェア620は、ローカルファイル用のNULLストリングである。ただし、リモートファイルにおいて、シェア620とは、当該ファイルネームのうち、当該ファイルネームをネットワークプロバイダのネームスペースにストアするパスを記述する部分をいう。
【0034】
親ディレクトリ630とは、最終コンポーネントを除去して得られるファイルネームのうちのフルパスを記述した部分をいう。
【0035】
ファイルネームにおいて各コンポーネントは、「/」又は「\」で区切られているが、最終コンポーネント640とは、ファイルネームストリングの末端にあるコンポーネントであってストリーム660を含むものをいう。
【0036】
拡張子650とは、当該ファィルネームのうち、最後の「.」から任意のストリームまでの部分をいう。
【0037】
ストリーム660とは、当該ファイルネームのうち、最終コンポーネントにある最初の「:」以降の部分をいう。
【0038】
一実施形態において、あるフラグメントにあっては、その特定フラグメントを取得するとオーバヘッドコストが高くなるので、あるネームタイプ(例えば、ショートネーム)に従ってオープンされたファイルには利用できない。
【0039】
フォーマット化、パース、及びキャッシングのためのプロセス
図7は、本発明に従ってパフォームされるファイルネームケリープロセスを示す流れ図である。このプロセスは、開始ブロック701から開始され、開始ブロック701において、図2のフィルタマネージャ120によってIRPが受け取られ、このIRPが、フィルタドライバ212A〜Cのうちの1つに通知される。プロセス700は、ブロック702に進む。
【0040】
ブロック702にて、フィルタマネージャ120は、通知を受けたフィルタドライバから、特定ファイルネームの要求を受け取る。一実施形態においては、このファイルネーム要求は、フィルタマネージャ120が受け取ったIRPに関係して行う。他の実施形態においては、このフィルタドライバが、このIRPに無関係なオペレーションの一部として、ネーム要求を開始することができる。ファイルネーム要求がフィルタマネージャによって受け取られると、このフィルタマネージャはファイルネームを検索する。ファイルネーム要求処理プロセスの例については、図8を参照して説明する際に、詳細に説明する。本処理は、判定ブロック703に進む。
【0041】
判定ブロック703において、当該ファイルネームに対応するFISが、このフィルタマネージャに対応するデータ構造(図4及び5を参照)内に前もってキャッシュされているか否かを判定する。仮にファイルネーム要求に対応するFISが前もってキャッシュされている場合には、本処理はブロック706にジャンプする。他方、仮にファイルネーム要求に対応するFISが以前にキャッシュされていない場合には、本処理はブロック704に進む。
【0042】
ブロック704において、このフィルタマネージャは、ファイルネームのために、ファイルネームプロバイダをコールする。特定フィルタドライバのためのファイルネームプロバイダは、ボリュームにある同一の物理ファイルと異ならせることができる。ファイルネームプロバイダとしてオペレートするフィルタドライバは、当該ファイルネームを、アルティチュードの高いフィルタドライバに提供するが、通常、アルティチュードの低いフィルタドライバには提供しない。例えば、第1フィルタドライバのアルティチュードを、ファイルネームプロバイダとしてオペレートしている第2フィルタドライバよりも高くすることができる。第1フィルタドライバのためのファイルネームプロバイダは、第2フィルタドライバとなる。しかし、仮に第3フィルタドライバのアルティチュードが第2フィルタドライバよりも低い場合には、第2フィルタドライバは、第3フィルタドライバのためのファイルネームプロバイダとならない。当該ファイルネームを提供するファイルネームプロバイダをコールするプロセスの例については、図9を参照して説明する際に、詳細に説明する。本処理はブロック705に進む。
【0043】
ブロック705において、ファイルネームプロバイダによって生成されたファイルネームためのFISが、フィルタマネージャによって提供されるデータ構造内にキャッシュされ、要求元のフィルタドライバにされる。フィルタマネージャ用のキャッシュのハンドリング(handling)は、ファイルネームに現在適用されているプロセスと、ファイルネームのタイプその他の要素とに依存する。FISを指し示すポインタは、フィルタマネージャによって、ファイルネーム要求を開始したフィルタドライバに戻される。ポインタは、フィルタドライバがFISのファイルネームポインタリストにアクセスすることによって、ネームフラグメントにアクセスできるようにするものである。FISをキャッシュしてこれを要求元のフィルタドライバに戻すための例示的プロセスについては、図10を参照して説明する際に、詳細に説明する。本処理はブロック706に進む。
【0044】
ブロック706において、フィルタドライバが、現在、FISを使用中であることを反映させるため、各FISに関係付けされている参照カウントが更新(又はインクリメント)される。一実施形態においては、図5に示したように、参照カウントが、各FISのプライベートヘッダに含められる。このFISに関係付けされているメモリは、参照カウントがゼロを超えていれば、有効である。任意のフィルタドライバが、このFISへの参照を獲得すると、この参照カウントがインクリメントされる。各フィルタドライバが、このFISへの参照を解放するとき、ネット(net)カウントがデクリメントされる。このネットカウントがゼロになると、このFISが削除され、当該メモリが消去される。参照カウントは、特定のFISと、このFISに関係付けされているファイルネームとを含むメモリが、少なくとも必要な限度において有効である、ことを保証する。本処理はブロック707に進み、ブロック707において本処理が終了する。
【0045】
一実施形態においては、プロセス700は、CREATEオペレーションに対しては、異なるオペレートをする。CREATEオペレーションにおいては、当該ファイルシステムによって当該ファイルがまだオープンされていないので、当該ファイルのSCBにリンクされたキャッシュデータ構造(例えば、FIS)は、まだ生成されていない。フィルタドライバによってpre―CREATE期間において要求されたファイルネームにあって、このファイルネームは、このファイルオブジェクトに関係付けされているオペレーションデータ構造(例えば、IRP_CTRL)キャッシュを試験することにより生成される。仮にオペレーションデータ構造キャッシュからファイルネームが生成できない場合には、ファイルネームプロバイダに対してこれらを生成するように要求される(図8を参照)が、ファイルネームは、post―CREATE期間に達するまで、オペレーションデータ構造キャッシュにキャッシュされる。post―CREATEにおいて、仮にCREATEオペレーションが正しく完了した場合には、キャッシュデータ構造が生成される。仮にこのファイルネームが有効であり(図10を参照)、トンネリング(tunneling)が発生していない(図12を参照)場合には、ファイルネームがキャッシュされる。
【0046】
図8は、本発明に従ってパフォームされるファイルネーム要求処理プロセスの例を示す流れ図である。図7のプロセス700がブロック702に進むと、本処理がブロック801から開始される。本処理はブロック802に進む。
【0047】
ブロック802において、このフィルタマネージャは、当該ファイルネームに関係付けされているファイルオブジェクトと、ファイルネームに対して要求されたフォーマット(例えば、ノーマライズド、オープンド、又はショート)とが含まれるファイルネームに対する要求を、フィルタドライバから受け取る。本処理はブロック803に進む。
【0048】
ブロック803において、このフィルタマネージャは、ファイルネーム要求を行ったフィルタドライバから、ファイルネームプロバイダを判定する。前述したように、第1フィルタドライバは、アルティチュードが、ファイルネームプロバイダとしてオペレートしている第2フィルタドライバよりも高いが、この第2フィルタドライバを、そのファイルネームケリーのためのファイルネームプロバイダとして利用する。ドライバスタック内におけるフィルタドライバの順番は、このフィルタマネージャによって予め決定される。加えて、ファイルネームプロバイダとしてオペレートすることを望むフィルタドライバは、フィルタマネージャとともに、予め登録される。仮に要求元のフィルタドライバのアルティチュードが、指定されたファイルネームプロバイダよりも高い場合には、そのインスタンスのファイルネームプロバイダは、そのアルティチュードが、要求元フィルタドライバに最も近いが、要求元フィルタドライバよりも低いファイルネームプロバイダである。仮に要求元フィルタドライバが、他に、アルティチュードの低いファイルネームプロバイダとしてオペレートしているフィルタドライバを有していない場合には、このファイルシステムは要求元フィルタドライバのためのファイルネームプロバイダとしてオペレートする。一度要求元フィルタドライバのためのファイルネームプロバイダが決定されると、本処理はブロック804に進む。
【0049】
ブロック804において、このフィルタマネージャによって提供されたデータ構造内に既にキャッシュさせることができるファイルネーム要求に対応するFISをサーチすることができる。図4に関連して既に述べたが、このデータ構造は、要求されたファイルネームフォーマット(例えば、ノーマライズド、オープンド、又はショート)に従って編成される。要求されたファイルネームフォーマットに対応するデータ構造は、2つのキー(Key1、Key2)(図5を参照)に従ってサーチされる。第1キーは、当該ファイルの特定のオープンインスタンスに関係付けされているファイルオブジェクトである。このファイルオブジェクトは、FISが、同一のストリームレベル又はファイルオブジェクトレベルで、キャッシュされるか否かを指定するのを、支援する。これについては図10を参照して詳細に述べる。第2キーは、ブロック803で識別されたファイルネームプロバイダである。仮にFISが予めストアされている場合には、2つのキー(Key1、Key2)に従って、フィルタドライバデータ構造をサーチして、現行のFISを突き止める。本処理はブロック805に進み、ついで図7のプロセス700に戻り、ブロック704に進む。
【0050】
図9は、本発明にしたがってパフォームされるファイルネーム生成プロセスの例を示す流れ図である。プロセス900は、図7のプロセス700がブロック704に進むと、ブロック901から開始される。本処理は判定ブロック902に進む。
【0051】
判定ブロック902において、アルティチュードの低いフィルタドライバがファイルネームプロバイダとしてオペレートしているか否かを判定する。オペレートしていない場合には、このファイルシステムによってファイルネームが提供され、本処理はブロック906に進む。しかし、仮にアルティチュードの低いフィルタドライバがフィルタドライバとしてオペレートしている場合には、本処理はブロック903に進む。
【0052】
ブロック903において、このファイルネームプロバイダからファイルネームを検索するため、ネームコールバックが利用される。使用されるコールバックのタイプは、デスティネーションファイルネームが要求元フィルタドライバによって要求されたか否かに依存する。このファイルネームプロバイダは、2つのコールバックを登録する。これら2つのコールバックのうちの一方のコールバック、すなわちCreateDestinationNameCallbackは、ファイルネームプロバイダよりも高いフィルタドライバによって、デスティネーションネームが要求されたとき、コールされる。その他方のコールバック、すなわちCreateFileNameCallbackは、ファイルネームプロバイダよりも高い第2フィルタによって、ファイルネーム(デスティネーションファイルネームにおいてはない)が要求されたとき、第1フィルタドライバをコールする。
【0053】
デスティネーションファイルネームは、リネームオペレーション又はハードリンク作成オペレーションを表すターゲットネームとして指定されるファイルネームである。ハードリンクとは、ボリューム上の同一の物理ビットが2つ以上のファイルネームを有する場合において、ファイルネームをエイリアシング(aliasing)することをいう。ボリューム上の同一の物理ビットに該当する幾つかのファイルネームは、それぞれハードリンクと呼ばれる。デスティネーションファイルネームは、リネーム又はハードリンクパラメータに従って、ファイルネームプロバイダによって生成される。一実施形態においては、このデスティネーションファイルネームは、2つのフォーマット、すなわちノーマライズドフォーマットか、オープンドフォーマットのうちの一方で提供することができる。本実施形態においては、これらファイルネームのフラグメントは、必ずしも全てが、初期に、ファイルネームからパースされるわけではない。ボリュームと、シェアフラグメントとが、初期に、このファイルネームからパースされる。一度FISを指し示すポインタがこのフィルタドライバに戻されると、このフィルタドライバは、さらに、最終コンポーネント、拡張子、ストリーム、及び親ディレクトリのフラグメントを、ファイルネームからパースするように要求することができる。
【0054】
一実施形態においては、デスティネーションファイルネームはフィルタマネージャによって提供されたデータ構造内にキャッシュされない(例えば、パーストリームコンテキスト)。その代わりに、デスティネーションファイルネームは、フィルタマネージャのオペレーション特有のデータ構造内にキャッシュされる(例えば、IRP_CTRL)。デスティネーションファイルネームは、リネーム又はハードリンク作成オペレーション中にキャッシュされる。一度ネームコールバックが利用されると、本処理はブロック904に進む。
【0055】
ブロック904において、このフィルタマネージャは、ファイルネームプロバイダからファイルネームを受け取るが、この受け取りは、ファイルネームプロバイダが、アルティチュードがこの要求元のフィルタドライバより低い別のフィルタドライバか、このファイルシステムかに関わらず、行なわれる。本処理はブロック905に進み、図7のプロセス700に戻り、ブロック705に進む。
【0056】
図10は、本発明に従ってパフォームされるファイルネームキャッシュプロセスの例を示す流れ図である。プロセス1000は、図7のプロセス700がブロック705に進むとき、ブロック1001から開始される。本処理は判定ブロック1002に進む。
【0057】
判定ブロック1002において、このフィルタマネージャが、ネームプロバイダから受け取ったファイルネームに対して、リネームが現在行なわれているか否かが判定される。リネームとは、ファイルリネーム、ディレクトリリネーム、又はハードリンク作成オペレーションをいう。フィルタマネージャが受け取ったファイルネームに影響を与えるリネームが開始されると、FISのキャッシングがサスペンド(suspend)され、このファイルネームに関係付けされているFISがキャッシュされないから、キャッシュの一部をパージ(purge)することができる。仮にリネーム中である場合には、本処理はブロック1009に進み、ブロック1009にて、このFISはキャッシュされず、本処理はブロック1010に進む。
【0058】
しかしながら、仮にリネーム中でない場合には、本処理はブロック1003に進み、特定のファイルネームのために作成されたFISに関係付けされているタイムスタンプ(TS)が、フィルタマネージャタイムスタンプ(FTS)と比較される。このフィルタマネージャタイムスタンプは、最後のリネームプロシージャが完了したタイムに対応する。仮にFISが作成された後か、又は作成された時に、リネームが完了した場合(例えば、FTS≧TS)には、このFISは、さらにファイルネームをケリーするためには、有効でない。しかしながら、仮にフィルタマネージャタイムスタンプがFISのタイプスタンプ未満である場合(例えば、FTS<TS)には、このFISは、さらにケリーするために、有効である。本処理は判定ブロック1004に進む。
【0059】
判定ブロック1004においては、比較の結果に従って、FISのタイムスタンプが、フィルタマネージャタイムスタンプ(FTS)がFISのタイムスタンプ(TS)よりも少ないことを示すか否かが判定される。タイムスタンプが、FISが今後のケリーに有効でないことを示す場合、プロセスはブロック1009に続き、FISはキャッシュされずに、本処理はブロック1010に進む。
【0060】
しかし、タイムスタンプが、FISが今後のケリーに有効であることを示す場合、本処理は判定ブロック1005に進む。
【0061】
判定ブロック1005においては、ファイルに関係付けされているファイルネームの数が判定される。前述したように、ボリュームにストアされたファイルは、それぞれファイルに関係付けされている一意のファイルネームを表す複数のハードリンクとすることができる。したがって、仮にハードリンクの数が1を超える場合には、ファイルは1を超える数のファイルネームを有する。特定のファイルに関係付けされているファイルネームの数が1を超えないときは、本処理は判定ブロック1006に進む。しかし、特定のファイル数に関係付けされているファイルネームの数が1を超える場合には、本処理はブロック1008に進む。
【0062】
判定ブロック1006において、このフィルタマネージャがファイルネームプロバイダから受け取ったたファイルネームがノーマライズドフォーマットか否かが判定される。このフィルタマネージャに戻されたファイルネームがノーマライズドフォーマットであるときは、本処理はブロック1007に進む。しかし、フィルタマネージャに戻されたファイルネームが、別のフォーマット、例えばショートファイルネーム又はオープンドファイルネームであるときは、本処理はブロック1006に進む。
【0063】
ブロック1007において、このフィルタマネージャが受け取ったファイルネームに関係付けされているFISは、ストリームレベルでキャッシュされる。ストリームレベルでキャッシュされたFISにより、FISを指し示すポインタを、特定のストリームに対応するファイルネームを要求する任意のフィルタドライバに戻すことができる。したがって、必要とする構造は少ない。というのは、特定のFISを、同一のストリームをシェアする複数のファイルオブジェクトのために、使用することができるからである。必要な構造が少なくなる。本処理はブロック1010に進み、ブロック1010にて、本処理は図7のプロセス700に戻り、ブロック706に進む。
【0064】
ブロック1008において、このファイルマネージャが受け取ったファイルネームに関係付けされているFISは、ファイルオブジェクトレベルでキャッシュされる。ファイルオブジェクトレベルでキャッシュされたFISは、ファイルの特定のオープンインスタンスに適用される。ファイルオブジェクトレベルでキャッシュされたFISは、特定のファイルオブジェクトに対応する。たとえ特定のファイルオブジェクトが同一のストリームを第2ファイルオブジェクトとシェアできる場合であっても、このファイルオブジェクトレベルでストアされたFISは、特定のファイルオブジェクトに適用されるが、第2ファイルオブジェクトには適用されない。本処理はブロック1010に進み、ブロック1010にて、本処理は図7の処理700に戻り、ブロック706に進む。
【0065】
一実施形態においては、このFISがもはや有効でないときには、このFISに関係付けされているメモリ空間は割り振られない。このメモリ空間を解放する前に、このフィルタマネージャはこのFISに関係付けされている参照カウントを試験する。特定のFISに関係付けされたメモリは、参照カウントがゼロに達するまでは、解放されない。
【0066】
リネーム
図11は、本発明に従ってパフォームされるリネームプロセスの例を示す流れ図である。プロセス1100は、リネームオペレーションが開始されるブロック1101から開始される。本処理は判定ブロック1102に進む。
【0067】
判定ブロック1102において、現在のリネームプロセスがディレクトリのリネームであるか否かを判定する。ファイルネームのリネームに比べて、ディレクトリリネームにおいては、ディレクトリに関係付けされた全てのファイルのファイルネームが変更される。仮に現在のリネームプロセスがディレクトリのリネームを含まない場合には、本処理は判定ブロック1104に進む。しかし、仮に現在のリネームプロセスがディレクトリのネームを変更している場合には、本処理はブロック1103に進む。
【0068】
ブロック1103において、ディレクトリネームの変更に応答して、当該ディレクトリに関係付けされているキャッシュが、フィルタマネージャと共にパージされる。キャッシュを参照するとき、このキャッシュには、特定のファイルネームのそれぞれのフォーマット(例えば、ノーマライズド、オープンド、ショート)に対するFISがそれぞれ含まれる。一実施形態においては、当該ディレクトリに関係付けされたキャッシュをパージするのは、ディレクトリリネームを反映するために、当該キャッシュを更新するのに利用されることになるであろうストリング比較よりも、効率的である。キャッシュをパージすることにより、その後に生成されるファイルネームが、ディレクトリのネーム変更を正確に反映できることを保証する。そして、これらフィルタドライバが、このフィルタマネージャに、新しいディレクトリネームを含むファイルネームをケリーするとき、当該キャッシュはリポピュレート(repopulate)される。本処理はブロック1107に進み、このプロセスは終了する。
【0069】
判定ブロック1104において、現在のリネームプロセスが、ハードリンク作成オペレーションに対応するか否かが判定される。ハードリンクが作成されると、このハードリンクは、ストリームレベルのファイルネームに影響を及ぼす。言い換えると、ストリームレベルでキャッシュされているFISは、このハードリンクが作成されたとき、当該ファイルの全てのオープンインスタンスに対しては、最早、有効ではない。仮にリネームプロセスがハードリンク作成オペレーションに対応する場合には、本処理はブロック1105に進む。
【0070】
ブロック1105において、ハードリンク作成オペレーションに関係付けされたキャッシュが、ストリームレベルでパージされる。このハードリンクに従うファイルネームに対応しているFISは、ストリームレベルでは、最早、ストアされず(仮に、元々、ストリームレベルでストアされている場合には、図10を参照)、ファイルオブジェクトレベルでストアされる。複数のハードリンクを有するファイルに関係付けされているFISは、ファイルの特定のオープンインスタンスにとっては有効であるが、ファイルの全てのオープンインスタンスにとって有効ではない。本処理はブロック1107に進み、本プロセスは終了する。
【0071】
あるいはまた、仮にリネームプロセスがディレクトリリネーム又はハードリンク作成オペレーションに対応していない場合には、本処理はブロック1106に進む。
【0072】
ブロック1106において、特定のファイルネームに関係付けされているキャッシュが、ストリームレベルとファイルオブジェクトレベルの両方でパージされる。したがって、ファイルネームの各フォーマットについてそれぞれのFISが、フィルタマネージャに関係付けされたデータ構造(図4及び5を参照)から削除される。本処理はブロック1107に続き、プロセスは終了する。
【0073】
ファイルネームトンネリング
一実施形態においては、本発明には、ファイルシステムのファイルネームトンネリング機能を補償する機能が含まれる。ファイルネームトンネリングには、ファイルシステム内にストアされたファイルネームに含まれたロングネーム/ショートネームのペアが関係する。トンネリングは、オペレーティングシステムによってサポートされ、その結果として、ファイルシステムの任意のリード/ライトでトンネリング機能を利用することができる。ファイルネームトンネリングは、ロングネーム又はショートネームのいずれかが削除されたときに生じるが、ある時間間隔で、再び作成される。ファイルネームトンネリング機能により、ファイルのメタ情報(meta―info)を短い期間に持続できるファイルシステムを当てにするプログラムと互換性を有することができる。このファイルトンネリングは、削除又はリネームの後に生じ、新しいディレクトリエントリにメタ情報を再導入した後に生じる(仮に作成又はリネームがあって、当該ネームのファイルが短期間で再び現れる場合)。ネームがディレクトリから除去されると(リネーム又は削除)、そのショートネーム/ロングネームのペアと、他の属性、例えば作成時間がキャッシュにセーブされ、除去されたネームによってキー(key)される。ネームがディレクトリに追加されると(リネーム又は作成)、リストア(restore)するための情報があるか否かをみるため、当該キャッシュがサーチされる。
【0074】
図12は、本発明に従ってパフォームされるファイルネームトンネリングプロセスであって、図7のプロセス700と並行してランされるものを示す流れ図である。プロセス1200はブロック1201から開始される。本処理は判定ブロック1202に進む。
【0075】
判定ブロック1202において、この要求元フィルタドライバは、要求しているファイルネームがファイルネームトンネリングの候補であるか否かを認識する。ファイルネームトンネリングの候補は、8.3フォーマットの部分を含むファイルである。ファイルネームトンネリングは、ショートネーム(すなわち8.3フォーマットのファイルネーム)がファイルネームのノーマライズドバージョンに拡張されるとき、ファイルネームのノーマライズドバージョンに影響を及ぼす。ファイルに関係付けされているショートファイルネームを変更すると、これに従って、ノーマライズドネームも変更される。同様にして、ショートファイルネームが変更されない場合には、ノーマライズドファイルネームも変更されない。仮に当該ファイルネームがトンネリング候補でない場合には、本処理はブロック1205に進み、ファイルネームのCREATEオペレーションが正しく(successfully)完了し、ファイルネームに対応するFISがキャッシュされる。しかし、仮にファイルネームがトンネリング候補である場合には、本処理は判定ブロック1203に進む。
【0076】
判定ブロック1203において、ファイルネーム候補であるファイルネームに対してトンネリングが生じたか否かが判定される。トンネリングが生じていない場合には、本処理はブロック1205に進み、ファイルネームのためのCREATEオペレーションが正しく完了すると、ファイルネームに対応するFISがキャッシュされる。しかし、仮にファイルネーム作成中にファイルネームトンネリングが使用された場合には、本処理はブロック1204に進む。
【0077】
ブロック1204において、作成されたファイルネームに関係付けされているFISは、フィルタマネージャによって提供されたデータ構造内にキャッシュされない。本処理はブロック1206に進み、本プロセスが終了する。
【0078】
本明細書、例、及びデータにおいては、本発明のコンポーネントを製造し使用することを完全に説明するものである。本発明の多くの実施形態は、本発明の精神及び範囲を逸脱することなく実施できるから、本発明は、添付の特許請求の範囲を逸脱するものではない。
【図面の簡単な説明】
【0079】
【図1】本発明の一実施形態において使用することができるコンピューティング装置の例を示す図である。
【図2】本発明を実施するための環境の例を示すブロック図である。
【図3】本発明に係るNTFSファイルシステムのデータ構造を示すブロック図である。
【図4】本発明に係るファイルオブジェクトとファイルマネージャデータ構造との間の関係を示すブロック図である。
【図5】本発明に係るフィルタマネージャに関係付けされた他のデータ構造を示すブロック図である。
【図6】本発明に従ってラベル付けされたフラグメントを有するファイルネームの例を示す図である。
【図7】本発明に従ってパフォームされるファイルネームケリープロセスの例を示す流れ図である。
【図8】本発明に従ってパフォームされるファイルネーム要求処理プロセスの例を示す流れ図である。
【図9】本発明に従ってパフォームされるファイルネーム生成プロセスの例を示す流れ図である。
【図10】本発明に従ってパフォームされるファイルネーム情報構造キャッシュプロセスの例を示す流れ図である。
【図11】本発明に従ってパフォームされるリネームプロセスの例を示す流れ図である。
【図12】本発明に従ってパフォームされるファイルネームトンネリングプロセスの例を示す流れ図である。
【符号の説明】
【0080】
100 コンピューティング装置
102 プロセシングユニット
104 システムメモリ
105 オペレーティングシステム
106 プログラムモジュール
107 プログラムデータ
109 リムーバブルストレージ
110 ノンリムーバブルストレージ
112 入力装置
114 出力装置
116 通信コネクション
118 他のコンピューティング装置
120 フィルタマネージャ
Claims (25)
- ファイルシステムフィルタドライバのためのファイルネームを管理する方法において、
指定されたフォーマットのファイルネームに対するファイルネーム要求を第1フィルタドライバから受け取るステップと、
前記ファイルネーム要求に対応するファイルネームを生成するため、ファイルネームプロバイダをコールするステップと、
生成されたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造をキャッシュするステップと、
前記生成されたファイルネーム情報構造を指し示すポインタを前記第1フィルタドライバに戻すステップと
を備えたことを特徴とする方法。 - 請求項1において、前記ファイルネームを生成するため前記ファイルネームプロバイダをコールする前に、前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定するステップをさらに備えたことを特徴とする方法。
- 請求項1において、前記第1フィルタドライバが前記生成されたファイルネーム情報構造を利用している間、当該ファイルネーム情報構造が維持されるようにするため、前記ポインタが前記第1フィルタドライバに戻されたとき、前記生成されたファイルネーム情報構造に関係付けされている参照カウントを更新するステップをさらに備えたことを特徴とする方法。
- 請求項1において、前記生成されたファイル情報構造をキャッシュする前に前記ファイルネーム情報構造が有効か否かを判定されるようにするため、前記ポインタが前記第1フィルタドライバに戻されたとき、前記生成されたファイルネーム情報構造に関係付けされているタイムスタンプを更新するステップをさらに備えたことを特徴とする方法。
- 請求項1において、前記ファイルネーム要求を受け取るステップは、前記第1フィルタドライバの識別子を指定するファイルネーム要求と、前記ファイルネームによって識別されたファイルのオープンインスタンスに対応するファイルオブジェクトと、前記ファイルネームのフォーマットとを受け取るステップをさらに備えたことを特徴とする方法。
- 請求項5において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、及びショートのうちの少なくとも1つを備えたことを特徴とする方法。
- 請求項1において、前記ファイルネームプロバイダをコールするステップは、第2のフィルタドライバが前記ファイルネームプロバイダとしてオペレートしているとき、アルティチュードの低い第2のフィルタドライバを、前記第1フィルタドライバからコールするステップをさらに備えたことを特徴とする方法。
- 請求項1において、リネームプロシージャが進行中であるか否かを判定するステップと、
前記リネームプロシージャが前記ファイルネームの少なくとも一部分を変更するとき、ファイルネーム情報構造のキャッシュの適正な部分をパージするステップと
をさらに備えたことを特徴とする方法。 - 請求項1において、前記生成されたファイルネーム情報構造は、ストリームレベル及びファイルオブジェクトレベルのうちの一方のレベルでキャッシュされることを特徴とする方法。
- 請求項1において、
リネームが進行中であるか否かを判定するステップと、
前記リネームが終了したタイムと、前記生成されたファイルネーム情報構造が作成されたタイムとを比較するステップと、
前記生成されたファイルネーム情報構造が作成されたタイムと比較した結果、前記リネームが終了したタイムの方が遅い場合に、前記ポインタを前記第1フィルタドライバに戻さないようにするステップと
をさらに備えたことを特徴とする方法。 - 請求項1において、ファイルネームトンネリングがいつ生じたかを判定してファイルネームトンネリングを補償するステップと、
ファイルネームトンネリングが生じたとき、前記生成されたファイルネーム情報構造をキャッシュしないようにするステップと
をさらに備えたことを特徴とする方法。 - コンピュータ実行可能なコンポーネントを有するコンピュータ可読媒体において、
ファイルシステムのための第1フィルタドライバにより行なわれるファイルネーム要求を管理する第1コンポーネントを備え、
前記第1コンポーネントは、
指定されたフォーマットを有するファイルネームのための前記第1フィルタドライバから、ファイルネーム要求を受け取り、
前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定し、前記ファイルネーム情報構造が予めキャッシュされている場合に、前記ファイルネーム情報構造を指し示すポインタを前記フィルタドライバに戻し、
前記ファイルネーム情報構造が予めキャッシュされていない場合に、
前記ファイルネーム要求に対応するファイルネームを生成するため、ファイルネームプロバイダをコールし、
生成されたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造をキャッシュし、
前記生成されたファイルネーム情報構造を指し示すポインタを前記第1コンポーネントに戻す
ように構成したことを特徴とするコンピュータ可読媒体。 - 請求項12において、前記第1コンポーネントは、前記第1フィルタドライバによるファイルネーム要求に加えて、前記ファイルシステムのための入力/出力要求を、前記第1コンポーネントが受け取って処理するようにするため、前記ファイルシステムと、オペレーティングシステムに関係付けされている外部アプリケーションとの間に、配置されたことを特徴とするコンピュータ可読媒体。
- 請求項12において、前記第1コンポーネントは、ファイルネーム情報構造がキャッシュされるファイルネームキャッシュデータ構造を含み、
前記ファイルネームキャッシュデータ構造は、前記ファイルネーム情報構造に対応する前記ファイルネームのフォーマットに従って編成される
ことを特徴とするコンピュータ可読媒体。 - 請求項12において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、又はショートのうちの少なくとも1つであることを特徴とするコンピュータ可読媒体。
- データ構造でエンコードされたコンピュータ可読媒体において、
参照カウント及びタイムスタンプを含むヘッダと、
ボリューム上のファイルのファイルネームを指し示すポインタを含む第1データフィールドと
を備え、
前記参照カウントは、前記参照カウントが、予め定めた整数に到達するまで、前記データ構造が削除されないようにするのを支援し、
前記タイムスタンプは、特定の時点で前記データ構造の有効性を判定するのを支援し、
前記ポインタは、それぞれフィルタネームの予め定めたフラグメントを指し示す
ことを特徴とするコンピュータ可読媒体。 - 請求項16において、前記ヘッダ及び第1データフィールドは、前記ファイルネームのフォーマットに従って配置されたツリーデータ構造内にストアされ、
前記フォーマットは、ノーマライズド、オープンド、又はショートのうちの少なくとも1つである
ことを特徴とするコンピュータ可読媒体。 - 請求項17において、前記ツリーデータ構造は、
特定のノードが、前記ファイルネームに対応する前記データ構造を指し示すポインタを提供するようにするため、
前記ボリューム上の前記ファイルに関係付けされたファイルオブジェクトに対応する第1キーと、前記ファイルネームのプロバイダに対応する第2キーとに従ってアクセスされるノードを含む
ことを特徴とするコンピュータ可読媒体。 - ファイルシステムフィルタドライバのためのファイルネームを管理するためのコンピュータ実行可能命令を有するコンピュータ可読媒体において、
前記命令は、
指定されたフォーマット内のファイルネームに対するファイルネーム要求を、前記第1フィルタドライバから受け取るステップと、
前記ファイルネーム要求を満たすファイルネーム情報構造が予めキャッシュされているか否かを判定し、前記ファイルネーム情報構造が予めキャッシュされている場合に、前記ファイルネーム情報構造を指し示すポインタを前記フィルタドライバに戻すステップと、
前記ファイルネーム情報構造が予めキャッシュされていない場合には、
前記ファイルネーム要求に対応するファイルネームを生成するため、ファイルネームプロバイダをコールするステップと、
生成されたファイルネーム情報構造であって、前記ファイルネームプロバイダから受け取った前記ファイルネームに対応するファイルネーム情報構造をキャッシュし、
前記生成されたファイルネーム情報構造を指し示すポインタを、前記第1フィルタドライバに戻すステップと
を備えたことを特徴とするコンピュータ可読媒体。 - 請求項19において、前記生成されたファイルネーム情報構造が前記第1フィルタドライバに使用される間維持されるようにするため、前記ポインタが前記第1フィルタドライバに戻されるとき、前記生成されたファイルネーム情報構造に関係付けされている参照カウントを更新するステップを備えたことを特徴とするコンピュータ可読媒体。
- 請求項19において、前記生成されたファイル情報構造をキャッシュする前に、前記ファイルネーム情報構造が有効か否かを判定するようにするため、前記ポインタが前記第1フィルタドライバに戻されるとき、前記生成されたファイルネーム情報構造に関係付けされているタイムスタンプを更新するステップを備えたことを特徴とするコンピュータ可読媒体。
- 請求項19において、前記ファイルネーム要求を受け取るステップは、前記第1フィルタドライバの識別子を指定するファイルネーム要求と、前記ファイルネームによって識別されたファイルのオープンインスタンスに対応するファイルオブジェクトと、前記ファイルネームのフォーマットとを受け取ることを特徴とするコンピュータ可読媒体。
- 請求項22において、前記ファイルネームのフォーマットは、ノーマライズド、オープンド、及びショートのうちの少なくとも1つを含むことを特徴とするコンピュータ可読媒体。
- 請求項19において、リネームプロシージャが進行中であるか否かを判定するステップと、
前記リネームプロシージャが前記ファイルネームのうちの少なくとも一部を変更する場合に、ファイルネーム情報構造のキャッシュの適正な部分をパージするステップとを備えたことを特徴とするコンピュータ可読媒体。 - 請求項19において、前記生成されたファイルネーム情報構造は、ストリームレベル及びファイルオブジェクトレベルのうちの一方のレベルでキャッシュされることを特徴とするコンピュータ可読媒体。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/187,119 US7444317B2 (en) | 2002-06-28 | 2002-06-28 | System and method for managing file names for file system filter drivers |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004038960A true JP2004038960A (ja) | 2004-02-05 |
JP4359448B2 JP4359448B2 (ja) | 2009-11-04 |
Family
ID=29718034
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003172376A Expired - Fee Related JP4359448B2 (ja) | 2002-06-28 | 2003-06-17 | ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US7444317B2 (ja) |
EP (1) | EP1376405A3 (ja) |
JP (1) | JP4359448B2 (ja) |
CN (1) | CN1331059C (ja) |
TW (1) | TWI327702B (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017511515A (ja) * | 2014-08-25 | 2017-04-20 | バイドゥ オンライン ネットワーク テクノロジー (ベイジン) カンパニー リミテッド | ファイルをスキャンする方法及び装置 |
Families Citing this family (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9361243B2 (en) | 1998-07-31 | 2016-06-07 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US6993603B2 (en) | 2002-12-09 | 2006-01-31 | Microsoft Corporation | Managed file system filter model and architecture |
US7308689B2 (en) * | 2002-12-18 | 2007-12-11 | International Business Machines Corporation | Method, apparatus, and program for associating related heterogeneous events in an event handler |
US20050091389A1 (en) * | 2003-10-27 | 2005-04-28 | Qi Emily H. | Media access control architecture |
US7272606B2 (en) * | 2003-11-26 | 2007-09-18 | Veritas Operating Corporation | System and method for detecting and storing file content access information within a file system |
US7328217B2 (en) * | 2003-11-26 | 2008-02-05 | Symantec Operating Corporation | System and method for detecting and storing file identity change information within a file system |
US7415480B2 (en) | 2003-12-10 | 2008-08-19 | Symantec Operating Corporation | System and method for providing programming-language-independent access to file system content |
JP4859348B2 (ja) * | 2004-02-18 | 2012-01-25 | 大日本印刷株式会社 | コンピュータシステム |
US7636710B2 (en) * | 2004-03-04 | 2009-12-22 | Symantec Operating Corporation | System and method for efficient file content searching within a file system |
US8306991B2 (en) * | 2004-06-07 | 2012-11-06 | Symantec Operating Corporation | System and method for providing a programming-language-independent interface for querying file system content |
US7831552B2 (en) | 2004-06-07 | 2010-11-09 | Symantec Operating Corporation | System and method for querying file system content |
US7657530B2 (en) * | 2004-06-07 | 2010-02-02 | Symantec Operating Corporation | System and method for file system content processing |
US7562216B2 (en) * | 2004-06-28 | 2009-07-14 | Symantec Operating Corporation | System and method for applying a file system security model to a query system |
US7437375B2 (en) * | 2004-08-17 | 2008-10-14 | Symantec Operating Corporation | System and method for communicating file system events using a publish-subscribe model |
US7487138B2 (en) * | 2004-08-25 | 2009-02-03 | Symantec Operating Corporation | System and method for chunk-based indexing of file system content |
US20060074912A1 (en) * | 2004-09-28 | 2006-04-06 | Veritas Operating Corporation | System and method for determining file system content relevance |
US7610307B2 (en) | 2004-11-30 | 2009-10-27 | Microsoft Corporation | Method and system of detecting file system namespace changes and restoring consistency |
US7496565B2 (en) * | 2004-11-30 | 2009-02-24 | Microsoft Corporation | Method and system for maintaining namespace consistency with a file system |
US9639554B2 (en) | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
US8321439B2 (en) | 2004-12-17 | 2012-11-27 | Microsoft Corporation | Quick filename lookup using name hash |
US7873596B2 (en) | 2006-05-23 | 2011-01-18 | Microsoft Corporation | Extending cluster allocations in an extensible file system |
US8606830B2 (en) | 2004-12-17 | 2013-12-10 | Microsoft Corporation | Contiguous file allocation in an extensible file system |
EP1684151A1 (en) | 2005-01-20 | 2006-07-26 | Grant Rothwell William | Computer protection against malware affection |
US20060259516A1 (en) * | 2005-05-11 | 2006-11-16 | Stakutis Christopher J | Nondisruptive method for encoding file meta-data into a file name |
US7680830B1 (en) * | 2005-05-31 | 2010-03-16 | Symantec Operating Corporation | System and method for policy-based data lifecycle management |
US8280908B2 (en) * | 2006-06-30 | 2012-10-02 | Microsoft Corporation | Merging file system directories |
US20080040404A1 (en) * | 2006-08-11 | 2008-02-14 | Microsoft Corporation | Host computer I/O filter re-directing potentially conflicting I/O commands from instantiations of legacy application |
US20080183662A1 (en) * | 2007-01-31 | 2008-07-31 | Benjamin Clay Reed | Resolving at least one file-path for a change-record of a computer file-system object in a computer file-system |
US7814077B2 (en) * | 2007-04-03 | 2010-10-12 | International Business Machines Corporation | Restoring a source file referenced by multiple file names to a restore file |
US7844596B2 (en) * | 2007-04-09 | 2010-11-30 | International Business Machines Corporation | System and method for aiding file searching and file serving by indexing historical filenames and locations |
US9032087B2 (en) * | 2007-07-13 | 2015-05-12 | International Business Machines Corporation | Providing a fine-grained response from a coarse-grained service object |
US10606901B1 (en) * | 2007-09-28 | 2020-03-31 | Emc Corporation | Data disposition services orchestrated in an information management infrastructure |
US8495030B2 (en) * | 2011-01-06 | 2013-07-23 | International Business Machines Corporation | Records declaration filesystem monitoring |
JP5483561B2 (ja) * | 2010-02-25 | 2014-05-07 | 楽天株式会社 | ストレージ装置、サーバ装置、ストレージシステム、データベース装置、データの提供方法、及び、プログラム |
CN102567325B (zh) * | 2010-12-14 | 2013-11-27 | 无锡华润矽科微电子有限公司 | 一种解析fat文件系统的文件名的方法 |
US8996807B2 (en) | 2011-02-15 | 2015-03-31 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a multi-level cache |
US9003104B2 (en) | 2011-02-15 | 2015-04-07 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a file-level cache |
US9201677B2 (en) | 2011-05-23 | 2015-12-01 | Intelligent Intellectual Property Holdings 2 Llc | Managing data input/output operations |
US8874823B2 (en) | 2011-02-15 | 2014-10-28 | Intellectual Property Holdings 2 Llc | Systems and methods for managing data input/output operations |
CN102194079B (zh) * | 2011-03-18 | 2013-09-11 | 北京思创银联科技股份有限公司 | 文件访问过滤方法 |
US9323778B2 (en) * | 2011-04-06 | 2016-04-26 | Dell Products L.P. | Virtual disk utility |
US9116812B2 (en) | 2012-01-27 | 2015-08-25 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a de-duplication cache |
US9612966B2 (en) | 2012-07-03 | 2017-04-04 | Sandisk Technologies Llc | Systems, methods and apparatus for a virtual machine cache |
US10339056B2 (en) | 2012-07-03 | 2019-07-02 | Sandisk Technologies Llc | Systems, methods and apparatus for cache transfers |
US9218368B2 (en) * | 2012-12-21 | 2015-12-22 | Dropbox, Inc. | System and method for organizing files based on an identification code |
US9842053B2 (en) | 2013-03-15 | 2017-12-12 | Sandisk Technologies Llc | Systems and methods for persistent cache logging |
CN104252441A (zh) * | 2013-06-27 | 2014-12-31 | 镇江雅迅软件有限责任公司 | 一种基于时间戳规则的编码机制实现方法 |
CN104462191A (zh) * | 2014-10-27 | 2015-03-25 | 广州三星通信技术研究有限公司 | 一种文件名修改方法及电子设备 |
US10116688B1 (en) * | 2015-03-24 | 2018-10-30 | Symantec Corporation | Systems and methods for detecting potentially malicious files |
US10489349B2 (en) * | 2015-11-04 | 2019-11-26 | Dell Products L.P. | Protecting files and folders on a shared application layer |
CN105912482B (zh) * | 2016-06-24 | 2019-05-28 | 飞天诚信科技股份有限公司 | 一种irp的处理方法及过滤驱动 |
US11412005B2 (en) * | 2019-08-29 | 2022-08-09 | Juniper Networks, Inc. | Lawfully intercepting traffic for analysis based on an application identifier or a uniform resource locator (URL) associated with the traffic |
US20230118118A1 (en) * | 2021-10-19 | 2023-04-20 | EMC IP Holding Company LLC | Client-based name cache handling external to distributed storage system |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6286013B1 (en) | 1993-04-01 | 2001-09-04 | Microsoft Corporation | Method and system for providing a common name space for long and short file names in an operating system |
US5748980A (en) * | 1994-05-27 | 1998-05-05 | Microsoft Corporation | System for configuring a computer system |
US5745752A (en) * | 1994-12-13 | 1998-04-28 | Microsoft Corporation | Dual namespace client having long and short filenames |
US6438320B1 (en) * | 1996-10-16 | 2002-08-20 | Canon Kabushiki Kaisha | File management system for managing data of photographed images |
US5909559A (en) * | 1997-04-04 | 1999-06-01 | Texas Instruments Incorporated | Bus bridge device including data bus of first width for a first processor, memory controller, arbiter circuit and second processor having a different second data width |
US6105119A (en) * | 1997-04-04 | 2000-08-15 | Texas Instruments Incorporated | Data transfer circuitry, DSP wrapper circuitry and improved processor devices, methods and systems |
CN1154948C (zh) * | 1997-08-27 | 2004-06-23 | 英业达股份有限公司 | 文件格式转换方法 |
US6092163A (en) * | 1998-12-04 | 2000-07-18 | W. Quinn Associates, Inc. | Pageable filter driver for prospective implementation of disk space quotas |
US6026402A (en) * | 1998-01-07 | 2000-02-15 | Hewlett-Packard Company | Process restriction within file system hierarchies |
WO1999042934A2 (en) * | 1998-02-20 | 1999-08-26 | Storm Systems, Llc | File system performance enhancement |
US6148336A (en) * | 1998-03-13 | 2000-11-14 | Deterministic Networks, Inc. | Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering |
US6574618B2 (en) * | 1998-07-22 | 2003-06-03 | Appstream, Inc. | Method and system for executing network streamed application |
US6330573B1 (en) | 1998-08-31 | 2001-12-11 | Xerox Corporation | Maintaining document identity across hierarchy and non-hierarchy file systems |
US6389459B1 (en) * | 1998-12-09 | 2002-05-14 | Ncr Corporation | Virtualized storage devices for network disk mirroring applications |
US6460048B1 (en) | 1999-05-13 | 2002-10-01 | International Business Machines Corporation | Method, system, and program for managing file names during the reorganization of a database object |
US6393517B1 (en) * | 1999-08-31 | 2002-05-21 | Sony Corporation | SCSI port filter driver for enhanced audio data |
US6654888B1 (en) * | 1999-12-31 | 2003-11-25 | International Business Machines Corporation | Installing and controlling trial software |
US7150018B2 (en) | 2000-02-16 | 2006-12-12 | Microsoft Corporation | Method and system for deterministic ordering of software modules |
US6647473B1 (en) * | 2000-02-16 | 2003-11-11 | Microsoft Corporation | Kernel-based crash-consistency coordinator |
US6802021B1 (en) * | 2001-01-23 | 2004-10-05 | Adaptec, Inc. | Intelligent load balancing for a multi-path storage system |
US6769071B1 (en) * | 2001-01-23 | 2004-07-27 | Adaptec, Inc. | Method and apparatus for intelligent failover in a multi-path system |
-
2002
- 2002-06-28 US US10/187,119 patent/US7444317B2/en not_active Expired - Fee Related
-
2003
- 2003-06-17 JP JP2003172376A patent/JP4359448B2/ja not_active Expired - Fee Related
- 2003-06-23 EP EP03014101A patent/EP1376405A3/en not_active Withdrawn
- 2003-06-24 TW TW092117175A patent/TWI327702B/zh not_active IP Right Cessation
- 2003-06-30 CN CNB031457355A patent/CN1331059C/zh not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017511515A (ja) * | 2014-08-25 | 2017-04-20 | バイドゥ オンライン ネットワーク テクノロジー (ベイジン) カンパニー リミテッド | ファイルをスキャンする方法及び装置 |
Also Published As
Publication number | Publication date |
---|---|
EP1376405A3 (en) | 2006-05-03 |
CN1331059C (zh) | 2007-08-08 |
US20040002942A1 (en) | 2004-01-01 |
TW200408980A (en) | 2004-06-01 |
EP1376405A2 (en) | 2004-01-02 |
TWI327702B (en) | 2010-07-21 |
US7444317B2 (en) | 2008-10-28 |
CN1477518A (zh) | 2004-02-25 |
JP4359448B2 (ja) | 2009-11-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4359448B2 (ja) | ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法 | |
US7860907B2 (en) | Data processing | |
JP4255373B2 (ja) | ネットワークファイルシステムのための管理および同期化アプリケーション | |
KR100981857B1 (ko) | 인덱스 키를 사용하여 검색 범위를 제한하기 위한 시스템및 방법 | |
US7752226B1 (en) | Reverse pathname lookup by inode identifier | |
US5950198A (en) | Processes and apparatuses for generating file correspondency through replication and synchronization between target and source computers | |
US8386494B2 (en) | Providing data structures for determining whether keys of an index are present in a storage system | |
US7720869B2 (en) | Hierarchical structured abstract file system | |
US20060059204A1 (en) | System and method for selectively indexing file system content | |
US8095678B2 (en) | Data processing | |
US7591019B1 (en) | Method and system for optimization of anti-virus scan | |
US8090925B2 (en) | Storing data streams in memory based on upper and lower stream size thresholds | |
CN113515487B (zh) | 查询目录的方法、计算设备和分布式文件系统 | |
EP1325409A2 (en) | A shared file system having a token-ring style protocol for managing meta-data | |
JP5241298B2 (ja) | 履歴上のファイル名およびロケーションをインデックス付きにすることによりファイル・サーチおよびファイル操作を支援するためのシステムおよび方法 | |
US8176087B2 (en) | Data processing | |
US7693883B2 (en) | Online data volume deletion | |
US8886656B2 (en) | Data processing | |
US20200081925A1 (en) | Method and system for cached early-binding document search | |
JP4825504B2 (ja) | データ登録・検索システムおよびデータ登録・検索方法 | |
US8290993B2 (en) | Data processing | |
WO2021017655A1 (zh) | 获取索引节点号的方法、装置、计算设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060526 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090206 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090507 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090710 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090810 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120814 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130814 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |