JP4430722B2

JP4430722B2 - マルチプロトコルの統一ファイルロッキング

Info

Publication number: JP4430722B2
Application number: JP2008148947A
Authority: JP
Inventors: アンドレア・ボー
Original assignee: ネットアップ，インコーポレイテッド
Priority date: 1997-12-05
Filing date: 2008-06-06
Publication date: 2010-03-10
Anticipated expiration: 2018-11-30
Also published as: US20030065796A1; CA2312492C; JP2008305405A; CA2312492A1; EP1034493A1; US6516351B2; JP2001526426A; WO1999030254A1; US20020019874A1; US7293097B2

Description

本発明は、マルチプロトコルファイルサーバにおけるロッキングに関するものである。

統合されたコンピュータネットワークにおいて、複数のクライアントデバイスがファイルを共有することが好ましい。１つの既知の方法は、それら複数のクライアントデバイスからのファイルサーバ要求を受け取りかつ応答できるネットワークファイルサーバを、ファイルを記憶するために設けることである。これらのファイルサーバ要求は、ファイルサーバプロトコルを用いて作成される。このファイルサーバプロトコルは、ファイルサーバとクライアントデバイスの両方によって認識され順守されている。ファイルはファイルサーバに記憶されているので、複数のクライアントデバイスが、ファイルに対して同時にアクセスすることができる。

この技術分野における１つの問題は、複数のさまざまなファイルサーバプロトコルがあることである。それぞれは、ファイルオペレーションに対して異なるセマンティクスを有する。１つのファイルサーバが複数のファイルサーバプロトコルを認識するようにできることが知られているが、多くのファイルサーバプロトコルは、ファイルロッキングおよびファイル共有に関して、異なりかつ互換性のないセマンティクスを有するので、特に困難である。互換性のないロッキングセマンティクスは、複数のさまざまなクライアントデバイスにおいて、１つのファイルシステムを規定する障害となる。第１クライアントデバイスが第１ファイルサーバプロトコル（第１ファイルロッキングセマンティクス）に依存するならば、第２ファイルサーバプロトコル（第２ファイルロッキングセマンティクス）を用いる第２クライアントデバイスは、第１ファイルクライアントデバイスにおけるアプリケーションが完全に作動しなくなるようにするかもしれない。したがって、各ファイルサーバプロトコルの正しいオペレーションは、他の全てのファイルサーバプロトコルによるファイルロッキングセマンティクスが一致するかどうかに左右される。

例えば、ＵＮＩＸオペレーティングシステム（またはその変形）を用いるデバイスで一般的に使用されるプロトコルは、ＮＦＳ（ネットワークファイルシステム(Network File System)）プロトコルである。Ｗｉｎｄｏｗｓオペレーティングシステム（またはその変形）は、「ＰＣＮＦＳ」インプリメンテーションによってＮＦＳプロトコルも使用することができる。ＮＦＳプロトコルは、ステイトレス(stateless)であるように作成され、そのためファイルを共有できなくするようなセマンティクスを備えていない、またはファイルが１つのクライアントデバイスに制限されるセマンティクスを備えていない。それに対して、Ｗｉｎｄｏｗｓオペレーティングシステム（またはその変形）を用いるデバイスで一般的に使用されるプロトコルは、ＣＩＦＳ（コモンインターネットファイルシステム(Common Internet File System)）プロトコルである。ＣＩＦＳプロトコルは、範囲の広い強制ファイルロッキングセマンティクスを有する。ＣＩＦＳクライアントデバイスは、このセマンティクスに依存し、また順守している。

既知のシステムにおいて、ＮＦＳプロトコルは、付属のファイルロッキングプロトコル、つまりＮＬＭ（ネットワークロックマネージャ(Network Lock Manager)）が追加されているが、ＮＦＳプロトコルは、ＮＬＭロックを単なる勧告として扱っている。この方法がファイルロッキングセマンティクスをＮＦＳアプリケーションに与えるという目的を達成し、ＮＦＳアプリケーションがこの方法を使用しても、この方法によって、ＮＦＳアプリケーションがファイルロッキングセマンティクスを無視することを妨げることはできないし、クライアントデバイスが複数のさまざまなファイルサーバプロトコルのファイルロッキングセマンティクスに左右されない。

したがって、さまざまなファイルサーバプロトコルを用いるクライアントデバイスにおいてファイルロッキングセマンティクスを強制的に実行するシステムおよび方法を提供することが好ましい。これが、本発明の実施の形態において得られる利点である。この実施の形態において、複数の同一ファイルロッキングセマンティクスが、マルチプロトコルファイルサーバのカーネル（kernel）に統合され、サーバによって認識されるさまざまなファイルサーバプロトコルのいずれを使用してもクライアントデバイスにおいて強制的に実行される。好ましい実施の形態において、クライアントデバイスがネットワークファイルサーバ上にある共有されたファイルシステムにアクセスしているときに、ＣＩＦＳプロトコルの特定のファイルロッキングセマンティクスは、ＮＦＳクライアントデバイスがＣＩＦＳクライアントデバイスと同時に利用できるように実行されて、データの保全性を保護する。

なお、特開平６−１９７７１号公報に記載されたファイル管理機構では、異種プロトコルを使用するクライアントによるファイルの共用が記載されている。
特開平６−１９７７１号公報

本発明は、複数のさまざまなファイルサーバプロトコルを正しく同時に利用するための方法およびシステムを提供する。複数のさまざまなファイルサーバプロトコルを認識するファイルサーバは、同一のマルチプロトコルロックマネージメントシステム（同一のファイルロッキングセマンティクスを含む）を規定する。それは、全てのクライアントデバイスに対して同一のファイルロッキングセマンティックスを実施し、またファイルサーバによって認識されたプロトコルを実施する。好ましい実施の形態において、第１のファイルサーバプロトコル（例えば、ＣＩＦＳ）は、アパチュニスティックファイルロッキング技術によって、強制的なファイルオープンおよびファイルロッキングのセマンティクスを実施する。それに対して、第２のファイルサーバプロトコル（例えば付属プロトコルＮＬＭつきのＮＦＳ）は、ファイルオープンのセマンティクスがなく、助言的なバイトレンジロッキングのセマンティクスとファイルロッキングのセマンティクスを規定するだけである。

いずれかのクライアントデバイスがデータの読み出しまたは書き込みを行うまたは新しいファイルロックまたはバイトレンジロックを獲得する前に、始めのクライアントデバイスがいずれのクライアントデバイスであっても、さらに現在のロックに対して始めのファイルサーバプロトコルまたはファイルロッキングプロトコルがいずれのプロトコルであっても、ファイルサーバは、いずれかのクライアントデバイスが獲得していようとしているロックが現在のロックと矛盾していないかどうか判定することを同一のファイルロッキングのセマンティクスは、規定している。ＣＩＦＳクライアントデバイスがデータの読み出しまたは書き込みを試行するケースにおいては、クライアントデバイスがファイルを開けるとき、ファイルサーバはこの判定を実行する。ＣＩＦＳクライアントデバイスがバイトレンジロックを要求するケースにおいては、クライアントデバイスがバイトレンジロックを要求するとき、ファイルサーバはこの判定を実行する。ＮＦＳクライアントデバイスのケースにおいては、クライアントデバイスが実際に読み出しまたは書き込み要求を発するとき、またはＮＦＳクライアントデバイスが、バイトレンジの読み出しまたは書き込みを実施する意図を示すＮＬＭバイトレンジロックを要求するとき、ファイルサーバはこの判定を実行する。ファイルロッキングのセマンティクスを実行することによって、ＮＦＳクライアントデバイスによる悪影響からファイルデータを保護する。

本発明の第２の態様において、ファイルを開ける際に、「アップロック」（アパチュニスティックロック）、つまり１つのクライアントだけにファイルの読み出しまたは書き込みを行うことを認める排他的なファイルロックを、ＣＩＦＳクライアントデバイスは獲得することが可能である。クライアントデバイスが、アップロックされたファイルに対して、ノンＣＩＦＳ（つまり、ＮＦＳまたはＮＬＭ）プロトコル要求を発するとき、ファイルサーバは、ＣＩＦＳクライアントデバイスに対してアップロックブレークメッセージを送る、このアップロックブレークメッセージは、ＣＩＦＳクライアントデバイスが、全てのキャッシュされた書き込み操作を実施する機会を与え、さらにはファイルを閉じる機会を与えてもよい。ＮＦＳおよびＮＬＭ要求によりアップロックをブレークすることを認めることにより、ファイルデータの保全性を保護すると同時にＮＦＳクライアントデバイスによりファイルデータを利用できることを保証する。

本発明の第３の態様において、ＣＩＦＳクライアントデバイスは、ファイルシステムにおける１つのディレクトリに対する「チェンジモニタリング」ロックを獲得することができる。該ディレクトリにおいて変化が生じたときに、ファイルサーバは、変化が生じたことをＣＩＦＳクライアントデバイスに対して通知する。（ディレクトリにおける変化とは、ディレクトリ内でのファイルの作成、ファイルの削除、ファイルの改名、ディレクトリ内へのファイルの移動、ディレクトリ外へのファイルの移動を含む。）ファイルサーバは、ＣＩＦＳクライアントデバイスおよびノンＣＩＦＳクライアントデバイスの両方によってディレクトリにおいて変化が生じていないか注目しており、その変化を「チェンジモニタリング」ロックを有するＣＩＦＳクライアントデバイスに通知する。

以下の説明において、本発明の好ましい実施の形態は、好ましいプロセスステップとデータ構造について記載されている。この出願明細書を精読すると、当業者は、本発明の実施の形態が、この出願明細書に記載された特定のプロセスステップとデータ構造用に作成された汎用プロセッサと、特殊用途プロセッサと、その他の回路とを用いて実施されることが分かり、さらに本発明の実施の形態が、この出願明細書に記載された特定のプロセッサステップとデータ構造を実施するために、不適当な実験または更なる発明を必要としないことが分かる。

システム構造（クライアント／サーバ）
図１は、マルチプロトコルファイルサーバを含むシステムの第１のブロック図を示す。
システム１００は、ファイルサーバ１１０と、コンピュータネットワーク１２０と、複数のクライアントデバイス１３０とを含む。

ファイルサーバ１１０は、プロセッサ１１１と、大容量記憶装置１１２とを含む。大容量記憶装置１１２は、記憶し検索するためのデータを有する複数のファイル１１３を記憶し検索することができる。プロセッサ１１１は、ネットワーク１２０から複数の要求メッセージ１２１を受信し、コマンドおよびデータとしてメッセージを解析し、大容量記憶装置１１２にあるファイル１１３を操作し、コマンドおよびデータに対する応答として応答メッセージを送信することができる。

ファイルサーバ１１０とクライアントデバイス１３０は、ネットワーク１２０に接続されており、ネットワーク１２０上で送信されるメッセージ１２１を用いて通信する。メッセージ１２１は、クライアントデバイス１３０によってファイルサーバ１１０に送信されるファイルシステム要求と、ファイルサーバ１１０によってクライアントデバイス１３０に送信されるファイルシステム応答とを含む。

システム構造（ファイルロッキングセマンティクス）
図２は、マルチプロトコルファイルサーバを含むシステムの第２のブロック図を示す。
システム１００は、Ｕｎｉｘクライアントデバイス２０１と、ＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２と、ＣＩＦＳＷｉｎｄｏｗｓクライアントデバイス２０３とを含む複数のクライアントデバイス１３０を含む。Ｕｎｉｘクライアントデバイス２０１は、Ｕｎｉｘオペレーティングシステムを実行し、Ｕｎｉｘ／ＮＦＳファイルサーバプロトコルを使用する。ＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２は、Ｗｉｎｄｏｗｓオペレーティングシステムを実行し、ＰＣＮＦＳファイルサーバプロトコルを使用する。ＣＩＦＳＷｉｎｄｏｗｓクライアントデバイス２０３は、Ｗｉｎｄｏｗｓオペレーティングシステムを実行し、ＣＩＦＳファイルサーバプロトコルを使用する。

Ｕｎｉｘクライアントデバイス２０１とＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２は、ＮＦＳファイルサーバプロトコルを用いてファイルサーバ１１０と通信する。ＮＦＳファイルサーバプロトコルは、ＮＦＳファイルサーバプロトコルパーサ２１１によってファイルサーバ１１０で認識される。ＣＩＦＳＷｉｎｄｏｗｓクライアントデバイス２０３は、ＣＩＦＳファイルサーバプロトコルを用いてファイルサーバ１１０と通信する。ＣＩＦＳファイルサーバプロトコルは、ＣＩＦＳファイルサーバプロトコルパーサ２１２によってファイル１１０で認識される。ＮＦＳファイルサーバプロトコルまたはＣＩＦＳファイルサーバプロトコルのいずれかを用いるメッセージは、プロセッサ１１１によって解析され、アップロックマネージャ２２０によって処理される。

アップロックマネージャ２２０は、ＣＩＦＳアップロックを有するファイル１１３へのアクセスを管理する。アップロックマネージャ２２０の操作は、図３と図５での説明でより詳細に記載される。アップロックマネージャエレメント２２０は、クロスプロトコルロックマネージャ２３０に接続される。

クロスプロトコルロックマネージャ２３０は、ファイルサーバ１１０のファイルロッキングセマンティクスを管理する。クロスプロトコルロックマネージャ２３０は、４つのタイプのロックに関する情報を処理し記録する。その４つのタイプは、ＣＩＦＳバイトレンジロック２４１と、ＣＩＦＳファイルロック２４２と、ＰＣＮＦＳ（ＮＬＭ）ファイルロック２４３と、ＮＬＭバイトレンジロック２４４とである。クロスプロトコルロックマネージャ２３０の操作は、図３と図４での説明でより詳細に記載される。

異なるファイルロッキングセマンティクス
図２についての記載で示されているように、ファイルサーバ要求メッセージ１４０は、Ｕｎｉｘクライアントデバイス２０１、ＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２、またはＣＩＦＳＷｉｎｄｏｗｓクライアントデバイス２０３から受信される。また、このファイルサーバ要求メッセージ１４０は、ＮＦＳファイルサーバプロトコルまたはＣＩＦＳファイルサーバプロトコルを使用することができる。それぞれが、異なるファイルサーバプロトコルを使用することに加えて、これらのタイプのクライアントデバイス１３０は、それぞれ、ファイルサーバ１１０によって与えられる異なるモデルのファイルロッキングを有する。

特に、ＮＦＳファイルサーバプロトコルは、いかなる形式のファイルオープンまたはファイルクローズのセマンティクスなしでも、ファイルシステムオペレーションの実行することを規定する。これらのＮＦＳファイルシステムオペレーションは、ファイルデータに対する読み出しまたは書き込みオペレーションか、またはファイルシステム操作（つまり、ディレクトリに対する読み出しおよび書き込みオペレーション）を含むことができる。ファイルシステム操作は、ファイルまたはディレクトリの作成、ファイルまたはディレクトリの改名、１つのディレクトリから別のディレクトリへのファイルの移動、ファイルシステムからのファイルまたはディレクトリの除去（削除）を含んでもよい。

ＮＬＭ付属プロトコルは、ファイルに関するバイトレンジロックの獲得と解除を規定する。これらのバイトレンジロックは「リードロック」であってもよい。リードロックは、（例えば、その他のクライアントデバイス１３０における）他の対応しているアプリケーションに働きかけて、特定のバイトレンジへの書き込みを控えさせる。その代わりとして、これらのバイトレンジロックは、「ライトロック」であってもよい。ライトロックは、その他の対応しているアプリケーションに働きかけて、特定のバイトレンジに対する読み出しまたは書き込みを控えさせる。

ＣＩＦＳファイルサーバプロトコルは、ファイル１１３におけるデータに対する読み出しオペレーションまたは書き込みオペレーションを行おうとする前に、ファイルオープンオペレーションを実行することと、オープンされたファイル１１３に関するファイルロックを獲得することとを規定している。ファイルオープン時に、ＣＩＦＳクライアントデバイス１３０は、所望のアクセスモード（リードオンリー(read-only)、ライトオンリー(write-only)、またはリードライト(read-write)）を指定し、同じファイル１１３をオープンしようとするその他のクライアントデバイス１３０に対して所望のディナイモード（ディナイノン(deny-none)、ディナイリード(deny-read)、ディナイライト(deny-write)、ディナイオール(deny-all)）を指定することができる。それ以後、ＣＩＦＳファイルシステムオペレーションは、オープンされているファイルに対するアクセスモードをチェックすることだけが必要である。ＣＩＦＳクライアントデバイス１３０は、クライアントデバイス１３０がオープンしているファイルにおけるバイトレンジに対してバイトレンジロックを指定することもできる。バイトレンジロックは、「ライトロック」（リードライトのアクセスモードと、ディナイオールのディナイモードとを有する）と呼ばれる排他的ロックか、「リードロック」（リードオンリーのアクセスモードと、ディナイライトのディナイモードとを有する）と呼ばれる非排他的ロックかのいずれかである。

ファイルサーバ１１０は、アクセスモードとディナイモードを組み合わせるロックモードを決定する。ここにおいて使用されているように、「ロックモード」という用語は、ファイルサーバ１１０によって設定された、アクセスモードとディナイモードとを組み合わせる同一のロックモードを表している。

ファイルオープン時に、ＣＩＦＳクライアントデバイス１３０は、アップロック（オパチュニスティックロック）を獲得することもできる。アップロックは、ファイルをオープンするＣＩＦＳクライアントデバイス１３０は、別のクライアントデバイス１３０がそのファイルを利用しようとしない限りファイルに対する排他的なアクセス権を有することを規定する。アップロックは、アップロックの排他性が他のクライアントデバイス１３０のアクセスによってブレークされるという警告のために、クライアントデバイス１３０が必要としている以上のファイルに対する排他性を規定する。

ファイルサーバ１１０は、ＮＦＳ（付属プロトコルＮＬＭありもしくは付属プロトコルＮＬＭなし）またはＣＩＦＳを用いて、複数のクライアントデバイス１３０間の正しい相互利用を規定する。正しく相互利用するために、ファイルサーバ１１０は、同一ファイルロッキングセマンティクスを規定する。好ましい実施の形態において、同一ファイルロッキングセマンティクスは以下の効果を有する。

ファイルサーバ１１０は、ＣＩＦＳクライアントによってオープンされかつ使用されている、ディナイライトまたはディナイオール等のディナイモードであるファイル１１３におけるデータに対して、Ｕｎｉｘクライアントデバイス２０１が上書きするＮＦＳライトオペレーションを実行することを防ぐ。

ファイルサーバ１１０は、Ｕｎｉｘクライアントデバイス２０１およびＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２が、ＣＩＦＳクライアントによってオープンされかつ使用されているファイル１１３を除去するまたは改名するというＮＦＳファイルシステムオペレーションを実行することを防ぐ。

Ｕｎｉｘクライアントデバイス２０１またはＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２が、ＣＩＦＳクライアントデバイスによってアップロックされたファイル１１３に対してデータを書きこむ、ファイル１１３を除去するまたはファイル１１３の名前を変えるために、ＮＦＳ要求を作成するとき、ファイルサーバ１１０は、ファイル１１３にＣＩＦＳアップロックセマンティクスを実施する。ファイルサーバ１１０は、アップロックブレークメッセージ１４０を、アップロックを保持するクライアントデバイス１３０に送信し、クライアントデバイス１３０から応答を受け取る。クライアントデバイス１３０がファイル１１３を閉じるならば、ＮＦＳ要求は続行し、ファイルサーバ１１０はそれを許可する。

Ｕｎｉｘクライアントデバイス２０１またはＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２が、ＣＩＦＳクライアントデバイスによってアップロックされたファイル１１３からデータを読み出すために、ＮＦＳ要求を作成するとき、ファイルサーバ１１０は、ファイル１１３に対してＣＩＦＳアップロックセマンティクスを実施する。ファイルサーバ１１０は、アップロックブレークメッセージ１４０を、アップロックを保持するクライアントデバイス１３０に送信し、クライアントデバイス１３０から応答を受け取る。クライアントデバイス１３０がファイル１１３を閉じるか、またはファイルのライトキャッシュをファイルサーバ１１０に書きこむときに、ＮＦＳ要求は続行し、ファイルサーバ１１０はそれを許可する。

ファイルサーバ１１０は、特定のロックモードに関して、ＣＩＦＳＷｉｎｄｏｗｓクライアントデバイス２０３からのファイルオープン要求と、ＰＣＮＦＳＷｉｎｄｏｗｓクライアントデバイス２０２からのＮＬＭファイルロック要求とに対する互換性をテストする。ＮＬＭ「ファイルロック」という用語は、ここでは、以下の書類において記載されるＮＬＭ「シェアーロック」という既知の用語の代わりに使用される。その書類は、Ｘ／ＯｐｅｎＣＡＥ仕様書、Ｘ／Ｏｐｅｎ相互作用プロトコル、ＸＮＦＳ第４版（Ｘ／Ｏｐｅｎドキュメント番号Ｃ２１８）であり、本明細書に完全に記載されているように参照として本明細書に含まれている。特定のロックモードは、要求されたアクセスモードおよびディナイモードを組み合わせることにより、ファイルサーバ１１０によって決定される。

これらの効果を生じさせるために、ファイルサーバ１１０は、以下のファイルロックマネージメントオペレーションを実行する。

ＣＩＦＳファイルオープン要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、現在のＣＩＦＳおよびＮＬＭファイルロックと矛盾し、かつ既存のＮＬＭバイトレンジロックと矛盾するファイルオープン要求をテストする。新しく要求されたファイルロックと比較するために、ファイルサーバ１１０は、現在のＮＬＭバイトレンジロックを、ディナイノンのディナイモードを有するものとして、また非排他性ロックであるリードオンリーのアクセスモードと排他性ロックであるリードライトのアクセスモードとを有するものとして扱う。

ＣＩＦＳバイトレンジロック要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、現在のＣＩＦＳおよびＮＬＭバイトレンジロックと矛盾するバイトレンジロック要求をテストする。

ＮＬＭバイトレンジロック要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、現在のＣＩＦＳおよびＮＬＭバイトレンジロックと矛盾し、かつ現在のＣＩＦＳファイルロックと矛盾するバイトレンジロック要求をテストする。

ＰＣＮＦＳクライアントデバイス１３０（ファイルオープン要求メッセージ１４０をシミュレートするために使用される）からのＮＬＭファイルロック要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、既存のＣＩＦＳおよびＮＬＭファイルロックとは相容れず、かつ既存のＮＬＭバイトレンジロックとは相容れないＮＬＭファイルロック要求をテストする。新たに要求されたＮＬＭファイルロックと比較するために、ファイルサーバ１１０は、既存のＮＬＭバイトレンジロックを、ディナイノンのディナイモードを有するものとして、また非排他性ロックであるリードオンリーのアクセスモードと、排他性ロックであるリードライトのアクセスモードとを有するものとして扱う。

オペレーション方法（マルチプロトコルファイルサーバ）
図３は、マルチプロトコルファイルサーバを操作する方法のプロセスフローチャートを示す。
マルチプロトコルファイルサーバの操作方法３００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。

フローポイント３１０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０を受け取れる状態にある。

ステップ３１１において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０を受け取り、解析する。ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０がＮＦＳファイルサーバプロトコル、ＮＬＭファイルロッキングプロトコル、ＣＩＦＳファイルロッキングプロトコルのいずれを使用するか判定する。ファイルサーバ要求メッセージ１４０が、ＮＦＳファイルサーバプロトコル、またはＮＬＭファイルロッキングプロトコルを使用するならば、方法３００は、ステップ３１２に続く。ファイルサーバリクエスト要求メッセージ１４０が、ＣＩＦＳファイルサーバプロトコルを使用するならば、方法３００は、ステップ３１３に続く。

ステップ３１２において、ファイルサーバ１１０は、要求メッセージ１４０がファイルシステムオペレーション（データの読み出しもしくは書き込み、またはディレクトリの変更等）を実行するためのＮＦＳファイルサーバ要求を含む。その代わりとして、ファイルサーバ１１０は、要求メッセージ１４０がＮＬＭバイトレンジロックを獲得するためのＮＬＭファイルロッキング要求を含む。どちらのケースにおいても、方法３００は、フローポイント３２０に続く。

ステップ３１３において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０がＣＩＦＳのリードもしくはライトオペレーションを実行することか、ＣＩＦＳバイトレンジロックを獲得することか、またはＣＩＦＳファイルオープンオペレーションを実行することか判定する。ファイルサーバ要求メッセージ１４０が、ＣＩＦＳバイトレンジロックを獲得することであるか、またはＣＩＦＳファイルオープンオペレーションを実行することであるならば、方法３００は、フローポイント３２０に続く。ファイルサーバ要求メッセージ１４０が、ＣＩＦＳのリードもしくはライトオペレーションを実行することであれば、方法はフローポイント３３０に続く。ファイルサーバ要求メッセージ１４０が、ＣＩＦＳ「チェンジ通知」要求であるならば、方法は、フローポイント３５０に続く（チェンジ通知要求は、図６の説明とともにさらに記載される）。

フローポイント３２０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０によって要求されたオペレーションとファイル１１３のファイルロッキングステータスとを比較できる状態にある。ファイル１１３のファイルロッキングステータスは、ファイル１１３に対する現在のファイルロックおよびバイトレンジロックを含む。

ステップ３２１において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０が対象にしているファイル１１３を判断し、このファイル１１３がアップロックされているかどうか判定する。ファイル１１３がアップロックされているならば、方法３００は、ステップ３２２に続く。ファイル１１３がアップロックされていないならば、方法３００は、ステップ３２３に続く。

ステップ３２２において、ファイルサーバ１１０は本明細書に記載されているようにアップロックをブレークする。ステップ３２２の実行は、図５についての説明でさらに記載される。アップロックをブレークさせることによって、ファイル１１３のファイルロッキングステータスを変化させることが可能である。

ステップ３２３において、ファイルサーバ１１０は、同一のファイルロッキングセマンティクスを用いて、要求されたオペレーションとファイル１１３のファイルロッキングステータスを比較する。このステップにおいて、要求されたオペレーションは、ＮＦＳの読み出しもしくは書き込みオペレーション、ＮＦＳもしくはＣＩＦＳのディレクトリ変更オペレーション、ＮＬＭのファイルロックもしくはバイトレンジロックを獲得しようとする試み、ＣＩＦＳファイルオープンオペレーションであってもよい。ステップ３２３の動作と、同一のファイルロッキングセマンティクスは、図４の説明とともにさらに記載される。この比較は、要求されたオペレーションが許容できることを示すならば、方法３００は、ステップ３２４に続く。要求されたオペレーションが許容できないのであれば、方法３００はステップ３２５に続く。

ステップ３２４において、ファイルサーバ１１０は、要求されたオペレーションを実行する。方法３００はフローポイント３４０に続く。

ステップ３２５において、ファイルサーバ１１０は、要求されたオペレーションの実行を拒絶し、エラーメッセージを伴ってクライアントデバイス１３０に対して応答する。方法３００は、フローポイント３４０に続く。

フローポイント３３０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０によって要求されたオペレーションと、ファイル１１３のファイルロッキングステータスと比較できる状態にある。

フローポイント３５０において、ファイルサーバ１１０は、本明細書に記載されているように、チェンジ通知オペレーションを実行できる状態にある。

ステップ３５１において、第１のＣＩＦＳクライアントデバイス１３０は、ディレクトリに対するファイルロックを要求し（ディレクトリをオープンするためにファイルシステム要求メッセージ１４０を用いて）、ディレクトリに対するファイルロックを、ディレクトリに関するチェンジモニタリングロックに変換する。このステップ３５１の実行は、図６の説明とともにさらに記載される。

フローポイント３４０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０に対して応答し、方法３００は、ファイルサーバ要求メッセージ１４０について完了する。

オペレーション方法（クロスプロトコルロックマネージャ）
図４は、マルチプロトコルファイルサーバにおけるクロスプロトコルロックマネージャを操作する方法のプロセスフローチャートを示す。

マルチプロトコルファイルサーバにおけるクロスプロトコルロックマネージャを操作する方法４００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。

フローポイント４１０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０における要求されたオペレーションを、ファイル１１３のファイルロッキングステータスと比較できる状態にある。

ファイルサーバ１１０は、同一のファイルロッキングセマンティクスを使用して、どのファイルサーバプロトコルで要求されたオペレーションのファイルロッキング状態でも同じ方法で作成する。同一のファイルロッキングセマンティクスは、同一の複数のファイルロックを識別する。それぞれのファイルロックは、要求しているクライアントデバイス１３０に対するアクセスモードと、全ての他のクライアントデバイス１３０に対するディナイモードとを含む。

好ましい実施の形態において、アクセスモードは、リードオンリー、ライトオンリー、またはリードライトの３つの可能性のうちの１つである。同様に、好ましい実施の形態において、ディナイモードは、ディナイノン、ディナイリード、ディナイライト、ディナイオールの４つの可能性のうちの１つである。

第１クライアントデバイス１３０がファイル１１３に対するファイルロックを獲得した後、第２クライアントデバイス１３０によって要求されかつファイルサーバ１１０によって決定されたロックモードが、ファイル１１３のファイルロッキングステータスと互換性があるならば、第２クライアントデバイス１３０は、ファイル１１３だけにアクセスすることができる。例えば、第１クライアントデバイス１３０は、ファイル１１３に対するディナイライトのディナイモードを有するファイルロックを獲得することができる。第２ＮＦＳクライアントデバイス１３０は、ファイル１１３に対して書き込もうとすることもできるし、または第２ＣＩＦＳクライアントデバイス１３０は、ライトアクセスを含むアクセスモードで、ファイル１１３をオープンしようとすることもできる。いずれもケースにおいても（ファイル１１３に対するファイルロックが、本明細書に記載されているように、アパチュニスティックロックでないならば）、ファイルサーバ１１０は、第２クライアントデバイス１３０による要求を拒否する。

本明細書に示されているように、ファイルサーバ１１０は、第２クライアントデバイス１３０によって使用されるファイルサーバプロトコルに応じて、たびたび第２クライアントデバイス１３０によって要求されるアクセスとファイルロックとの比較を実行する。

第２クライアントデバイス１３０が、ＣＩＦＳファイルサーバプロトコルを使用してファイル１１３をオープンするならば、ファイルサーバ１１０は、ファイルオープン時にファイル１１３のファイルロッキングステータスをチェックする。

第２クライアントデバイス１３０が、ＮＦＳファイルサーバプロトコルを使用してファイル１１３に対する読み出しまたは書きこみを実行するならば、実際にファイルシステムオペレーションを実行するときに、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスをチェックする。これは、ファイル１１３を動かす、移動させる、またはファイル１１３の名前を変える等のオペレーションのように、第１クライアントデバイス１３０の対象領域からファイルを移動させる影響を有するファイルシステムオペレーションにも当てはまる。

第２クライアントデバイス１３０がＣＩＦＳファイルサーバプロトコルを使用してバイトレンジロックを要求するならば、バイトレンジロックが要求されたときに、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスと、他のＣＩＦＳまたはＮＬＭバイトレンジロックとが矛盾しているかチェックする。バイトレンジロックが要求されたときに、ファイルサーバ１１０は、バイトレンジロックと他のＣＩＦＳファイルロックとが矛盾しているかチェックしない。それは、バイトレンジロックと他のＣＩＦＳファイルロックとが矛盾しているかは、ファイルオープン時にチェックされたからである。

第２クライアントデバイス１３０がＮＬＭプロトコルを使用してバイトレンジロックを要求するならば、バイトレンジロックが要求されたときに、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスが、現在のＣＩＦＳまたはＮＬＭバイトレンジロックと矛盾しているか、また現在のＣＩＦＳファイルロックと矛盾しているかチェックする。

ステップ４２１において、ファイルサーバ１１０は、ファイル１１３と関連するファイルロックがすでに２つ以上あるかどうか判断する。ファイルロックが２つ以上あるならば、方法４００は、ステップ４２２に続く。ファイルロックが２つ以上でないならば、方法は、ステップ４１１に続く。

ステップ４２２において、ファイルサーバ１１０は、ファイル１１３に関するファイルロックをファイル１１３に関する１つの同等のファイルロックに併合する。このステップ４２２を実行するために、すでに存在しているファイルロックが１つにまとめられるまで、ファイルサーバ１１０は、すでに存在しているファイルロックと追加するファイルロックとを表１において相互参照する。

表１は、１つにまとめられたファイルロッキングセマンティクスを用いて、マルチプロトコルファイルサーバにおけるロック変換表を示す。

ロック変換マトリックス
Ａ＝アクセスモード（Ｒ＝リード、Ｗ＝ライト、ＲＷ＝リードライト、ＡＮＹ＝Ｒ、Ｗ、ＲＷのいずれか）
Ｄ＝ディナイモード（ＤＮ＝ディナイノン、ＤＲ＝ディナイリード、ＤＷ＝ディナイライト、ＤＡ＝ディナイオール）

ステップ４１１において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０において要求されたオペレーションの種類を判断する。要求されたオペレーションがＣＩＦＳファイルオープンオペレーションであるならば、方法４００は、ステップ４２３に続く。要求されたオペレーションがＮＦＳファイルサーバオペレーションであるならば、方法４００は、ステップ４３１に続く。要求されたオペレーションが、バイトレンジロックについてのＣＩＦＳ要求またはＮＬＭ要求であるならば、ファイルシステム１１０は、ステップ４４１に続く。

ステップ４２３において、ファイルサーバ１１０は、ファイル１１３に関するファイルロックと、第２クライアントデバイス１３０によって要求されたファイルオープンとを比較する。このステップ４２３を実行するために、ファイルサーバ１１０は、すでに存在するファイルロックと、新しく要求されたアクセスモードおよびディナイモードとを表２において相互参照し、対応する表のエントリーに応じて新しく要求されたアクセスモードおよびディナイモードを許可するか、または拒否する。

ファイルサーバ１１０が、新しく要求されたアクセスモードおよびディナイモードを許可するならば、方法４００は、ステップ４２４を実行する。ファイルサーバ１１０が、新しく要求されたアクセスモードおよびディナイモードを拒否するならば、方法４００は、ステップ４２４を実行しない。

表２は、１つにまとめられたファイルロッキングセマンティクスを用いて、マルチプロトコルファイルサーバにおいて試行されたファイルロックの相互参照を示す。

表２において示されているように、すでに存在しているファイルロックと、新しく要求されたアクセスモードおよびディナイモードとの各ペアは、対応する決定を備えている。その決定により、新しく要求されたアクセスモードおよびディナイモードが拒否されるか、または許可される。

ファイルサーバ１１０は、現在のＣＩＦＳファイルロックと、ファイルオープンオペレーションを実行するための新しい要求との間の矛盾をチェックするならば、現在のＣＩＦＳファイルロックは、新しいファイルオープン要求において要求されたアクセスモードおよびディナイモードについて相互参照される。

ファイルサーバ１１０は、現在のファイルロックと、ファイルのリードオペレーションまたはライトオペレーションを実行するための新しいＮＦＳ要求との間の矛盾をチェックするならば、集合体ロックモード（現在のファイルロックの組み合わせ）は、新しい要求を実行するために必要とされるアクセスモードについて相互参照される。

ファイルサーバ１１０は、現在のファイルロックまたはバイトレンジロックと、ＮＬＭバイトレンジロックに対する新しい要求との間の矛盾をチェックするならば、現在のファイルロックとバイトレンジロックは、新しいＮＬＭバイトレンジロック要求と同等のロックモードについて相互参照される。現在のファイルロックを比較するために、ファイルサーバ１１０は、新たに要求されたＮＬＭバイトレンジロックを、ディナイノンのディナイモードを有するものとして、さらに非排他性ロック（「リードロック」とも呼ばれる）の場合、リードオンリーのアクセスモードを、排他性ロック（「ライトロック」とも呼ばれる）の場合、リードライトのアクセスモードを有するものとして扱う。既存のバイトレンジロックと比較するために、ファイルサーバ１１０は、新たに要求されたＮＬＭバイトレンジロックを、リードロックの場合、リードオンリーのアクセスモードとディナイライトのディナイモードとを有するものとして、さらにライトロックの場合、リードライトのアクセスモードとディナイオールのディナイモードとを有するものとして扱う。

次に、方法４００は、フローポイント４５０に続く。

ステップ４３１において、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスを、第２クライアントデバイス１３０によって要求されたオペレーションと比較する。このステップ４３１を実行するために、ファイルサーバ１１０は、ファイルロックに関するディナイモードと要求されたオペレーションとを比較し、その比較に応じて要求されたオペレーションを許可するか、または拒否する。

次に、方法４００は、フローポイント４５０に続く。

ステップ４４１において、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスを、第２クライアントデバイス１３０によって要求されたＮＬＭバイトレンジロックと比較する。好ましい実施の形態において、ＣＩＦＳバイトレンジロック要求は、バイトレンジロックのみについてチェックされる。それは、それらが以前のＣＩＦＳファイルオープンオペレーションを必要とし、現在のファイルロックは、以前のＣＩＦＳファイルオープンオペレーションのときに、すでにチェックされているからである。このステップ４４１を実行するために、ファイルサーバ１１０は、以前から存在するファイルロッキングステータスと要求されたバイトレンジロックを表３において相互参照し、対応する表エントリーに応じて要求されたバイトレンジロックを許可するか、または拒否する。

ファイルサーバ１１０が、新しく要求されたＮＬＭバイトレンジロックを許可するならば、方法４００は、ステップ４４２を実行する。ファイルサーバ１１０が、新しく要求されたバイトレンジロックを拒否するならば、方法４００は、ステップ４４２を実行しない。

表３は、１つにまとめられたファイルロッキングセマンティクスを用いて、マルチプロトコルファイルサーバにおける新たに要求されたＮＬＭバイトレンジロックと現在のファイルロックとの相互参照を示す。

表３において示されているように、既存のファイルロックと新たに要求されたＮＬＭバイトレンジロックの各ペアは、対応する決定を備えている。その決定により、新しく要求されたバイトレンジロックが拒否されるか、または許可される。

ステップ４４２において、ファイルサーバ１１０は、新しい追加のバイトレンジロックとして新しく要求されたバイトレンジロックとファイル１１３を関連付ける。

方法４００は、フローポイント４５０に続く。

フローポイント４５０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０において要求されたオペレーションと、ファイル１１３のファイルロッキングステータスを比較し、要求されたオペレーションを許可するか、または拒否する。

オペレーション方法（アップロックマネージャ）
図５は、マルチプロトコルファイルサーバにおけるアップロックマネージャを操作する方法のプロセスフローチャートを示す。

マルチプロトコルファイルサーバにおけるアップロックマネージャを操作する方法５００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。

アップロックは、Ｗｉｎｄｏｗｓオペレーティングシステム環境におけるファイルロッキングの分野において知られている。アップロックは、ワシントン州レドモンドにあるマイクロソフト社(Microsoft Corporation)で販売されている「ＷｉｎｄｏｗｓＮＴ４．０」オペレーティングシステムで利用できるマニュアルにさらに記載されている。このマニュアルは、例えばftp.microsoft.comのdirectory/developr/drg/CIFSのホストにある、ＦＴＰプロトコルによって入手可能なＣＩＦＳＩＥＴＦ仕様書を含む。この仕様書は、cifs6.docまたはcifs6.txtを含んでおり、本明細書において全部記載されているように参照によって本明細書に含まれる。

フローポイント５１０において、ファイルサーバ１１０は、ファイル１１３をオープンするためにＣＩＦＳ第１クライアントデバイス１３０からの要求を受け取れる状態にある。

ステップ５１１において、ファイルサーバ１１０は、ＣＩＦＳ第１クライアントデバイス１３０からファイル１１３に対するファイルオープン要求を受け取る。ファイルオープン要求はアクセスモードとディナイモードを指定する。

ステップ５１２において、ファイルサーバ１１０は、要求を許可すると判断し、第１クライアントデバイス１３０に対して指定されたアクセスモードとディナイモードとを有するファイルロックを与える。

ステップ５１３において、クライアントデバイス１３０が、ファイルオープン要求でアップロックを要求しているならば、ファイルサーバ１１０は、第１クライアントデバイス１３０に、第１クライアントデバイス１３０が実際必要としているものよりもできるだけ高い排他的レベルにあるアップロックを与える。

例えば、ＣＩＦＳ第１クライアントデバイス１３０が、リードオンリーのアクセスモードとディナイライトのディナイモードとを有するファイル１１３をオープンするとき、ファイルサーバ１１０は、そのタイプのファイルロックと、ファイル１１３とを対応させる。ファイルサーバ１１０は、さらにリードライトのアクセスモードとディナイオールのディナイモードとを有するファイル１１３と、アップロックとを対応させる。

フローポイント５２０において、ファイルサーバ１１０は、ファイル１１３に対するファイルロックについて、ＣＩＦＳ第１クライアントデバイス１３０からの要求に応答する。

フローポイント５３０において、第２クライアントデバイス１３０は、ファイル１１３をオープンしようと試みる。

ステップ５３１において、ファイルサーバ１１０は、第２ＣＩＦＳクライアントデバイス１３０からのファイルオープン要求か、またはＰＣＮＦＳクライアントデバイス１３０からのＮＬＭファイルロック要求かのいずれかを受け取る。

このステップ５３１の実行の一部として、ファイルサーバ１１０は、アップロックをブレークし、アップロックを保持している第１クライアントデバイス１３０からの応答を獲得する間に、ファイルサーバ１１０は、第２クライアントデバイス１３０による要求の実行を延期する。

ステップ５３２において、ファイルサーバ１１０は、「アップロックブレーク」メッセージ１４０をＣＩＦＳ第１クライアントデバイス１３０に送信することによってアップロックをブレークする。

第２クライアントデバイス１３０がＣＩＦＳクライアントデバイス１３０であるならば、アップロックがブレークされることは予想される。第２クライアントデバイス１３０が、ＮＦＳクライアントデバイス１３０であるならば、ＣＩＦＳ第１クライアントデバイス１３０が「アップロックブレーク」メッセージ１４０に対して応答するまで、ファイルサーバ１１０は、ＮＦＳ（またはＮＬＭ）プロトコル要求メッセージ１４０に対する応答を遅らせる。

ステップ５３３において、ＣＩＦＳ第１クライアントデバイス１３０は、「アップロックブレーク」メッセージ１４０を受け取り、以下の２つの方法のいずれかでメッセージ１４０に対して応答することができる。

ＣＩＦＳ第１クライアントデバイス１３０は、ファイル１１３をクローズすることができる（したがって、ファイルオープンと関連付けられたファイルロックを除去する）。

ＣＩＦＳ第１クライアントデバイス１３０は、クライアントデバイス１３０において、ローカルにキャッシュされた、ファイル１１３に対する全ての未実行のＣＩＦＳライト要求およびバイトレンジロック要求を出力してもよく（すなわち、ＣＩＦＳ第１クライアントデバイス１３０は、ファイルシステムオペレーションの結果をファイルサーバ１１０に転送する）、ＣＩＦＳ第１クライアントデバイス１３０がファイル１１３に対して獲得したリードアヘッドデータを捨ててもよい。リードアヘッドデータは捨てられるべきである。それは、第２クライアントデバイス１３０が、その後リードアヘッドデータを無効にする新しいデータをファイルに対して書き込む可能性があるためである。

ステップ５３４において、ファイルサーバ１１０は、ＣＩＦＳ第１クライアントデバイス１３０からの応答を受け取る。

ステップ５３５において、ファイルサーバ１１０は、ＣＩＦＳ第１クライアントデバイス１３０がファイル１１３をオープンにしたままであるか否かを判定する。オープンにしたままであるならば、ファイルサーバ１１０は、第２クライアントデバイス１３０による要求に包含されるロックモードを、ファイル１１３の新しいファイルロッキングステータスと比較する。ファイルサーバ１１０は、第２クライアントデバイス１３０による要求が続行することを許可するならば、フローポイント５４０に続く。ファイルサーバ１１０は、第２クライアントデバイス１３０による要求が続行することを許可しないならば、要求を拒否する。

フローポイント５４０において、ファイルサーバ１１０は、ステップ５３１において示された第２クライアントデバイス１３０からの要求を許可するように準備している。

オペレーションの方法（チェンジ通知マネージャ）
図６は、マルチプロトコルファイルサーバにおけるチェンジ通知マネージャの操作方法のプロセスフローチャートを示す。

マルチプロトコルファイルサーバにおけるチェンジ通知マネージャを操作する方法６００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。

フローポイント６１０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０を受け取れる状態にある。

ステップ６１１において、ファイルサーバ１１０は、ファイルサーバ１１０上のディレクトリを指定するファイルオープン要求メッセージ１４０を第１クライアントデバイス１３０から受け取る。ファイルサーバ１１０は、ファイルオープン要求を許可すると判断し、ディレクトリに関するＣＩＦＳファイルロックを第１ＣＩＦＳクライアントデバイス１３０に与える。

ステップ６１２において、ファイルサーバ１１０は、オープンディレクトリを参照するチェンジ通知要求メッセージをＣＩＦＳクライアントデバイス１３０から受け取って、オープンディレクトリに関するファイルロックをチェンジモニタリングロックに変換する。

ステップ６１３において、ファイルサーバ１１０は、オープンディレクトリに関するファイルロックを、指定されたディレクトリに関するチェンジモニタリングロックに変換する。

フローポイント６２０において、「チェンジモニタリング」ロックは指定されたディレクトリと関連付けられており、第１ＣＩＦＳクライアントデバイス１３０は、そのディレクトリに関する変化が通知される状態にある。

ステップ６２１において、ファイルサーバ１１０は、指定されたディレクトリに関する変更を要求しかつ第１クライアントデバイスへのチェンジ通知のきっかけとなるファイルサーバ要求メッセージ１４０を第２クライアントデバイス１３０から受け取る。（チェンジのタイプは、ファイル作成、ファイル削除、ファイル改名、ディレクトリ間のファイル移動、ファイル属性の変化、ファイル修正回数の変化を含む。）第２クライアントデバイス１３０からのファイルサーバ要求メッセージ１４０は、ＣＩＦＳまたはＮＦＳのいずれかである。第２クライアントデバイス１３０は、ＵｎｉｘＮＦＳクライアントデバイス２０１、ＰＣＮＦＳクライアントデバイス２０２、ＣＩＦＳＷｉｎｄｏｗｓクライアントデバイス２０３のいずれか１つである。

ステップ６２２において、ファイルサーバ１１０は、「チェンジモニタリング」ロックを保有する第１クライアントデバイス１３０に、ステップ６２１において示された変化を通知する。この変化は、複数のエントリーを含んでもよい。エントリーのそれぞれは、モニターされるディレクトリ内の変更されたファイル１１３またはサブディレクトリの名前と、変化のタイプの両方を特定する。対象とする第１クライアントデバイス１３０が１つ以上あるならば、ファイルサーバ１１０は、対象とする第１クライアントデバイスの全てに通知する。

チェンジ通知は、ＷｉｎｄｏｗｓＮＴオペレーティングシステム環境におけるファイルロッキングの分野において知られている。チェンジ通知は、ワシントン州レドモンドにあるマイクロソフト社(Microsoft Corporation)で販売されている「ＷｉｎｄｏｗｓＮＴ４．０」オペレーティングシステムで利用できるマニュアルにさらに記載されている。このマニュアルは、例えばftp.microsoft.comのdirectory/developr/drg/CIFSのホストにある、ＦＴＰプロトコルによって入手可能なＣＩＦＳＩＥＴＦ仕様書を含む。この仕様書は、cifs6.docまたはcifs6.txtを含んでおり、本明細書において全部記載されているように参照によって本明細書に含まれる。

フローポイント６３０において、ファイルサーバ１１０は、指定されたディレクトリに関する変化を第１ＣＩＦＳクライアントデバイス１３０に通知し、次のメッセージ１４０に対して準備する。

別の実施の形態
本明細書には好ましい実施の形態が開示されているが、多くの変形例が本発明の概念、範囲、精神内にある可能性があるものであり、これらの変形例は、本明細書を精読すれば当業者には明らかになるであろう。

技術的な付録
本発明に関するその他の情報、また更なる情報は、本明細書とともに記載された技術的な付録において含まれる。この技術的な付録は、３０ページ（図面を含む）を含み、本明細書に全部記載されたように、参照によって含まれる。

マルチプロトコルファイルサーバを含むシステムの第１のブロック図を示す。マルチプロトコルファイルサーバを含むシステムの第２のブロック図を示す。マルチプロトコルファイルサーバを操作する方法のプロセスフローチャートを示す。マルチプロトコルファイルサーバにおけるクロスプロトコルロックマネージャを操作する方法のプロセスフローチャートを示す。マルチプロトコルファイルサーバにおけるアップロックマネージャを操作する方法のプロセスフローチャートを示す。マルチプロトコルファイルサーバにおけるチェンジ通知マネージャを操作する方法のプロセスフローチャートを示す。

符号の説明

１００ファイルサーバ、１１１プロセッサ、１１２大容量記憶装置、１２０ネットワーク、１３０クライアントデバイス。

Claims

マルチプロトコルファイルサーバにより、前記マルチプロトコルファイルサーバにより具体化される複数のさまざまなファイルロッキングプロトコルを用いる１組のクライアントデバイスの間で同一のロッキングセマンティクスを実行する方法であって、
第１ロッキングプロトコルを用いて、選択されたデータセットに関するオパチュニスティックロックを第１クライアントデバイスに与えるステップと、
第２のクライアントデバイスが、前記第１ロッキングプロトコルと異なる第２プロトコルを用いて、選択された前記データセットへのアクセスを要求するとき、選択された前記データセットに関する前記オパチュニスティックロックをブレークするステップと、
前記同一のロッキングセマンティクスを用いて、前記複数のさまざまなファイルロッキングプロトコルの中の異なる複数のファイルロッキングプロトコルにおいて、前記データセットについてすでに存在している複数のファイルロックを１つの同等のファイルロックに併合し、前記１つの同等のファイルロックを用いて、選択された前記データセットに関するロッキングステータスを生成するステップと、
要求された前記アクセスを、生成された前記ロッキングステータスと比較するステップと、
要求された前記アクセスと、生成された前記ロッキングステータスの間に矛盾がないならば、要求された前記アクセスを与えるステップと
からなる方法。
前記生成ステップは、ロック互換性マトリックスを使用する請求項１に記載の方法。
前記比較ステップは、ロック変換マトリックスを使用する請求項１に記載の方法。
前記同一のロッキングセマンティクスは、アクセスタイプを特定するアクセスモードと、アクセスタイプをディナイするディナイモードとからなる請求項１に記載の方法。
前記ブレークするステップは、さらに、
アップロックブレークメッセージを前記第１クライアントデバイスに送信するステップと、
前記アップロックブレークメッセージへの応答が第１クライアントデバイスから受け取られるまで、要求されたオペレーションの実行を遅らせるステップと
を含むことを特徴とする請求項１に記載の方法。
複数のさまざまなファイルロッキングプロトコルを具体化するマルチプロトコルファイルサーバであって、
大容量記憶装置と、
ネットワークへのインタフェースと、
前記複数のさまざまなファイルロッキングプロトコルを用いる１組のクライアントデバイスにより前記インタフェースを介して前記大容量記憶装置にアクセスするための同一のロッキングセマンティクスを実行するプロセッサとからなり、
前記プロセッサは、
第１ロッキングプロトコルを用いて、選択されたデータセットに関するオパチュニスティックロックを第１クライアントデバイスに与える第１承諾手段と、
第２のクライアントデバイスが、前記第１ロッキングプロトコルと異なる第２プロトコルを用いて、選択された前記データセットへのアクセスを要求するとき、選択された前記データセットに関する前記オパチュニスティックロックをブレークするブレーク手段と、
前記同一のロッキングセマンティクスを用いて、前記複数のさまざまなファイルロッキングプロトコルの中の異なる複数のファイルロッキングプロトコルにおいて、前記データセットについてすでに存在している複数のファイルロックを１つの同等のファイルロックに併合し、前記１つの同等のファイルロックを用いて、選択された前記データセットに関するロッキングステータスを生成する生成手段と、
要求された前記アクセスを、生成された前記ロッキングステータスと比較する比較手段と、
要求された前記アクセスと、生成された前記ロッキングステータスの間に矛盾がないならば、要求された前記アクセスを与える第２承諾手段とを含む、
マルチプロトコルファイルサーバ。
前記生成手段はロック互換性マトリックスを使用する請求項６に記載のマルチプロトコルファイルサーバ。
前記比較手段はロック変換マトリックスを使用する請求項６に記載のマルチプロトコルファイルサーバ。
前記同一のロッキングセマンティクスは、アクセスタイプを特定するアクセスモードと、アクセスタイプをディナイするディナイモードとからなる請求項６に記載のマルチプロトコルファイルサーバ。
前記ブレーク手段は、さらに、
アップロックブレークメッセージを前記第１クライアントデバイスに送信する送信手段と、
前記アップロックブレークメッセージへの応答が第１クライアントデバイスから受け取られるまで、要求されたオペレーションの実行を遅らせる遅延手段と
を含むことを特徴とする請求項６に記載のマルチプロトコルファイルサーバ。