JP2001526426A

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

Info

Publication number: JP2001526426A
Application number: JP2000524743A
Authority: JP
Inventors: アンドレア・ボー
Original assignee: ネットワーク・アプライアンス・インコーポレイテッド
Priority date: 1997-12-05
Filing date: 1998-11-30
Publication date: 2001-12-18
Also published as: JP4430722B2; EP1034493A1; CA2312492A1; CA2312492C; WO1999030254A1; US7293097B2; US20030065796A1; US20020019874A1; JP2008305405A; US6516351B2

Abstract

(57)【要約】本発明は、同一のマルチプロトコルロックマネージメントシステムを用いて、複数のさまざまなファイルサーバプロトコルを正しく相互利用を行うための方法およびシステムを提供する。いずれかのクライアントデバイスがデータにアクセスする、またはロックを獲得する前に、始めのクライアントデバイスがいずれのクライアントデバイスであっても、さらに現在のロックに対して始めのファイルサーバプロトコルまたはファイルロッキングプロトコルがいずれのプロトコルであっても、ファイルサーバは、いずれかのクライアントデバイスが獲得していようとしているロックが現在のロックと矛盾していないかどうか判定する。第１のファイルサーバプロトコルは、アパチュニスティックファイルロッキング技術によって、強制的なファイルオープンおよびファイルロッキングのセマンティクスを実施する。それに対して、第２のファイルサーバプロトコルは、ファイルオープンのセマンティクスがなく、助言的なバイトレンジロッキングのセマンティクスとファイルロッキングのセマンティクスを規定するだけである。ファイルロッキングのセマンティクスを実行することによって、ＮＦＳクライアントデバイスによる悪影響からファイルデータを保護する。ファイルを開ける際に、「アップロック」（アパチュニスティックロック）、つまり１つのクライアントだけにファイルの読み出しまたは書き込みを行うことを認める排他的なファイルロックを、ＣＩＦＳクライアントデバイスは獲得することが可能である。クライアントデバイスが、アップロックされたファイルに対して、ノンＣＩＦＳプロトコル要求を発するとき、ファイルサーバは、ＣＩＦＳクライアントデバイスに対してアップロックブレークメッセージを送る、このアップロックブレークメッセージは、ＣＩＦＳクライアントデバイスが、全てのキャッシュされた書き込み操作を実施する機会を与え、さらにはファイルを閉じる機会を与えてもよい。ＮＦＳおよびＮＬＭ要求によりアップロックをブレークすることを認めることにより、ファイルデータの保全性を保護すると同時にＮＦＳクライアントデバイスによりファイルデータを利用できることを保証する。ＣＩＦＳクライアントデバイスは、ファイルシステムにおける１つのディレクトリに対する「チェンジモニタリング」ロックを獲得することができる。該ディレクトリにおいて変化が生じたときに、ファイルサーバーは、変化が生じたことをＣＩＦＳクライアントデバイスに対して通知する。ファイルサーバーは、ＣＩＦＳクライアントデバイスおよびノンＣＩＦＳクライアントデバイスの両方によってディレクトリにおいて変化が生じていないか注目しており、その変化を「チェンジモニタリング」ロックを有するＣＩＦＳクライアントデバイスに通知する。

Description

【発明の詳細な説明】

【０００１】発明の背景（１．発明の分野）本発明は、マルチプロトコルファイルサーバにおけるロッキングに関するもの
である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００６５】

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

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

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

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

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

【００７０】

【表２】

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

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

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

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

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

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

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

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

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

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

【００８１】

【表３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

【図１】マルチプロトコルファイルサーバを含むシステムの第１のブロッ
ク図を示す。

【図２】マルチプロトコルファイルサーバを含むシステムの第２のブロッ
ク図を示す。

【図３】マルチプロトコルファイルサーバを操作する方法のプロセスフロ
ーチャートを示す。

【図４】マルチプロトコルファイルサーバにおけるクロスプロトコルロッ
クマネージャを操作する方法のプロセスフローチャートを示す。

【図５】マルチプロトコルファイルサーバにおけるアップロックマネージ
ャを操作する方法のプロセスフローチャートを示す。

【図６】マルチプロトコルファイルサーバにおけるチェンジ通知マネージ
ャを操作する方法のプロセスフローチャートを示す。

───────────────────────────────────────────────────── 【要約の続き】ティクスを実行することによって、ＮＦＳクライアントデバイスによる悪影響からファイルデータを保護する。ファイルを開ける際に、「アップロック」（アパチュニスティックロック）、つまり１つのクライアントだけにファイルの読み出しまたは書き込みを行うことを認める排他的なファイルロックを、ＣＩＦＳクライアントデバイスは獲得することが可能である。クライアントデバイスが、アップロックされたファイルに対して、ノンＣＩＦＳプロトコル要求を発するとき、ファイルサーバは、ＣＩＦＳクライアントデバイスに対してアップロックブレークメッセージを送る、このアップロックブレークメッセージは、ＣＩＦＳクライアントデバイスが、全てのキャッシュされた書き込み操作を実施する機会を与え、さらにはファイルを閉じる機会を与えてもよい。ＮＦＳおよびＮＬＭ要求によりアップロックをブレークすることを認めることにより、ファイルデータの保全性を保護すると同時にＮＦＳクライアントデバイスによりファイルデータを利用できることを保証する。ＣＩＦＳクライアントデバイスは、ファイルシステムにおける１つのディレクトリに対する「チェンジモニタリング」ロックを獲得することができる。該ディレクトリにおいて変化が生じたときに、ファイルサーバーは、変化が生じたことをＣＩＦＳクライアントデバイスに対して通知する。ファイルサーバーは、ＣＩＦＳクライアントデバイスおよびノンＣＩＦＳクライアントデバイスの両方によってディレクトリにおいて変化が生じていないか注目しており、その変化を「チェンジモニタリング」ロックを有するＣＩＦＳクライアントデバイスに通知する。

Claims

【特許請求の範囲】

【請求項１】複数のさまざまなファイルサーバまたはファイルロッキング
プロトコルを用いて、複数のクライアントデバイスにおいて同一のファイルロッ
キングセマンティクスを実施するステップを含むファイルサーバを操作する方法
。
【請求項２】前記同一のファイルロッキングセマンティクスは、オパチュ
ニスティックロックを含み、オパチュニスティックロックは、第１プロトコルを用いる第１クライアントデ
バイスによって要求され、前記オパチュニスティックロックをブレークすることは、前記第１プロトコル
とは異なる第２プロトコルを用いる第２クライアントデバイスによって生じるこ
とを特徴とする請求項１に記載の方法。
【請求項３】前記第１プロトコルは、ＣＩＦＳを含む請求項２に記載の方
法。
【請求項４】前記第２プロトコルは、ＮＦＳまたはＮＬＭを含む請求項２
に記載の方法。
【請求項５】前記同一ファイルロッキングセマンティクスは、選択されたファイルに関するオパチュニスティックロックを、前記第１プロト
コルを用いる第１メッセージに応じて、前記第１クライアントデバイスに与える
ステップと、前記第２プロトコルを用いる第２メッセージに応じて、前記オパチュニスティ
ックロックをブレークするステップとを含むことを特徴とする請求項１に記載の方法。
【請求項６】前記ブレークするステップは、前記第２メッセージに応じて、アップロックブレークメッセージを前記第１ク
ライアントデバイスに送信するステップと、前記第２メッセージによって指示されるファイルシステム要求の実行を遅らせ
るステップと、前記アップロックブレークメッセージに対する応答を前記第１クライアントデ
バイスから受け取るステップと、前記の受け取るステップの後、前記第２メッセージを処理し、前記第２メッセ
ージに対して応答するステップとを含むことを特徴とする請求項５に記載の方法。
【請求項７】前記同一ファイルロッキングセマンティクスは、チェンジモ
ニタリングロックを含み、チェンジモニタリングロックは、第１プロトコルを用いる第１クライアントデバイスによって要求されることが
できるタイプであり、チェンジ通知が、前記第１プロトコルとは異なる第２プロトコルを用いる第２
クライアントデバイスによって生じるタイプであることを特徴とする請求項１に記載の方法。
【請求項８】前記第１プロトコルが、ＣＩＦＳを含む請求項７に記載の方
法。
【請求項９】前記第２プロトコルが、ＮＦＳを含む請求項７に記載の方法
。
【請求項１０】前記同一のファイルロッキングセマンティクスが、前記第１プロトコルを用いる第１メッセージに応じて、選択されたディレクト
リに関するチェンジモニタリングロックを前記第１クライアントデバイスに与え
るステップと、前記選択されたディレクトリに関する、前記第２プロトコルを用いる第２メッ
セージに応じて、チェンジ通知メッセージを前記第１クライアントデバイスに送
信するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１１】前記の実施するステップは、複数のさまざまなプロトコル
を認識するステップと、少なくとも前記プロトコルの１つを用いるメッセージに応じて、同一ファイル
ロッキングセマンティクスを規定するステップと、前記クライアントデバイス全てに対して前記同一のファイルロッキングセマン
ティクスを実施するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１２】前記同一のファイルロッキングセマンティクスは、前記第１プロトコルを用いる第１メッセージに応じて、オパチュニスティック
ロックを前記第１クライアントデバイスに与えるステップと、前記第２プロトコルを用いる第２メッセージに応じて、前記オパチュニスティ
ックロックをブレークするステップとを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】前記のブレークするステップは、前記第２メッセージに応
じて、アップロックブレークメッセージを前記第１クライアントデバイスに送信
するステップと、前記第２メッセージによって指定されるファイルシステム要求の実行を遅らせ
るステップと、前記アップロックブレークメッセージに対する応答を、前記第１クライアント
デバイスから受け取るステップと、前記の受け取るステップの後、前記第２メッセージを処理し、前記第２メッセ
ージに対して応答するステップとを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】前記同一のファイルロッキングセマンティクスを実施する
ステップは、前記第１プロトコルを用いる第１クライアントデバイスからの第１メッセージ
に応じて、チェンジモニタリングを承諾するステップと、前記第２プロトコルを用いる第２メッセージに応じて、チェンジ通知メッセー
ジを前記第１クライアントデバイスに送信するステップと、を含むことを特徴とする請求項１１に記載の方法。
【請求項１５】前記同一のファイルロッキングセマンティクスを実施する
前記のステップは、前記同一のファイルロッキングセマンティクスを妨害しようとする選択された
メッセージを認識するステップと、前記選択されたメッセージと関連付けられたプロトコルに適したエラー応答と
ともに、前記選択されたメッセージに対して応答するステップとを含むことを特徴とする請求項１１に記載の方法。
【請求項１６】前記同一のファイルロッキングセマンティクスを実施する
ステップは、前記の選択されたプロトコルにおいて、ファイルに関するバイトレンジロック
を獲得するための選択されたメッセージを認識するステップと、獲得する前記バイトレンジロックが、同一または他のプロトコルを用いるメッ
セージによって作成された既存のロックと矛盾するか否かテストするステップと
を含み、前記バイトレンジロックは、ロックタイプを有することを特徴とする請求項１
１に記載の方法。
【請求項１７】前記同一のファイルロッキングセマンティクスを実施する
ステップは、前記選択されたプロトコルにおいて、ファイルをオープンするための選択され
たメッセージを認識するステップを含み、前記選択されたメッセージは要求され
たアクセスモードを含み、前記同一のファイルロッキングセマンティクスを実施するステップは、さらに
前記要求されたアクセスモードを用いてオープンする前記ファイルが、同一また
は他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾す
るか否かをテストするステップを含むことを特徴とする請求項１１に記載の方法
。
【請求項１８】前記選択されたメッセージは、要求されたディナイモード
を含み、前記要求されたディナイモードを用いるオープンする前記ファイルが、同一ま
たは他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾
するか否かをテストするステップを含むことを特徴とする請求項１７に記載の方
法。
【請求項１９】前記同一のファイルロッキングセマンティクスを実施する
前記ステップは、前記の選択されたプロトコルにおいて、ファイルから読み出すための、または
ファイルに書き込むための選択されたメッセージを認識するステップと、ファイルからの読み出しが、またはファイルへの書きこみが、同一または他の
プロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否
かテストするステップとを含むことを特徴とする請求項１１に記載の方法。
【請求項２０】前記の実施するステップは、第１プロトコルを用いる第１
メッセージを受け取るステップと、第２プロトコルを用いる第２メッセージを受け取るステップと、前記第２メッセージによって要求される前記アクセスを前記ロックと比較し、
前記アクセスが前記ロックによって禁じられているならば、前記アクセスを拒否
するステップとを含み、前記第１メッセージは、選択されたファイルの少なくとも一部をロックするよ
うに作用し、前記第２メッセージは、前記一部へのアクセスを要求するように作
用することを特徴とする請求項１に記載の方法。
【請求項２１】前記第１プロトコルは、ＣＩＦＳを含む請求項２０に記載
の方法。
【請求項２２】前記第１プロトコルまたは前記第２プロトコルは、ＮＬＭ
を含む請求項２０に記載の方法。
【請求項２３】前記第２プロトコルは、ＮＦＳを含む請求項２０に記載の
方法。
【請求項２４】前記第２メッセージを受け取る前記ステップは、ファイル
に関するバイトレンジロックを獲得するための前記第２メッセージとして、前記
第２プロトコルを用いる前記第２メッセージを受け取るステップを含み、前記バ
イトレンジロックはロックタイプを有し、前記比較するステップは、獲得する、前記ロックタイプを有する前記バイトレ
ンジロックが、同一または他のプロトコルを用いるメッセージによって作成され
た既存のロックと矛盾するか否かをテストするステップを含む請求項２０に記載
の方法。
【請求項２５】前記テストするステップは、前記第２メッセージに使用さ
れるプロトコルに反応する請求項２４に記載の方法。
【請求項２６】前記テストするステップは、前記第１プロトコルに対して
はファイルオープン時に作用し、前記第２プロトコルに対してはアクセス時に作
用する請求項２４に記載の方法。
【請求項２７】前記テストするステップは、前記第１プロトコルに対して
はファイルオープン時に作用し、前記第２プロトコルに対してはロック要求時に
作用する請求項２４に記載の方法。
【請求項２８】前記第２メッセージを受け取る前記ステップは、ファイル
をオープンするための、前記第２プロトコルを用いる前記第２メッセージを認識
するステップを含み、前記第２メッセージは、要求されたアクセスモードを含み
、前記比較するステップは、前記要求されたアクセスモードを用いて、アクセス
する前記ファイルは、同一または他のプロトコルを用いるメッセージによって作
成された既存のロックと矛盾するか否かをテストするステップを含む請求項２０
に記載の方法。
【請求項２９】前記第２メッセージを受け取る前記ステップは、ファイル
から読み出すためのまたはファイルへ書き込むための、前記第２プロトコルを用
いる第２メッセージを認識するステップを含み、前記の比較するステップは、前記第２メッセージによってアクセスしようとす
る前記ファイルが、同一または他のプロトコルを用いるメッセージによって作成
された既存のロックと矛盾するか否かテストするステップを含む請求項２０に記
載の方法。
【請求項３０】前記第１メッセージを受け取る前記ステップは、前記第１
メッセージに応じて、アパチュニスティックロックを承諾するステップを含み、前記の比較するステップは、前記第２メッセージに応じて、前記アパチュニス
ティックロックをブレークするステップを含む請求項２０に記載の方法。
【請求項３１】前記のブレークするステップは、前記第２メッセージに応
じて、アップロックブレークメッセージを前記第１クライアントデバイスに送信
するステップと、前記第２メッセージによって指定されるファイルシステム要求の実行を遅らせ
るステップと、前記アップロックブレークメッセージに対する応答を前記第１クライアントデ
バイスから受け取るステップと、前記の受け取るステップの後、前記第２メッセージを処理し、前記第２メッセ
ージに対して応答するステップとを含むことを特徴とする請求項３０に記載の方法。
【請求項３２】前記アップロックブレークメッセージに対する前記応答は
、アップロックブレークアクノリッジメントメッセージまたはファイルクローズ
メッセージを含む請求項３１に記載の方法。
【請求項３３】前記ファイルロッキングセマンティクスは、第１プロトコ
ルを用いる第１クライアントデバイスによって要求されるアクセスモードとディ
ナイモードとに応じて決定されるロックモードを含む請求項１に記載の方法。
【請求項３４】前記ファイルロッキングセマンティクスは、第１プロトコルを用いる第１クライアントデバイスによって要求されるアクセ
スモードとディナイモードとに応じて決定される第１ロックモードと、前記第１プロトコルとは異なる第２プロトコルを用いる第２クライアントデバ
イスからのメッセージに応じて決定される第２ロックモードとを含み、前記ファイルサーバは、前記第１ロックモードと前記第２ロックモードとの比
較に反応することを特徴とする請求項１に記載の方法。
【請求項３５】前記比較は、ロック互換性マトリックスを含む請求項３４
に記載の方法。
【請求項３６】前記比較は、ロック変換マトリックスを含む請求項３４に
記載の方法。
【請求項３７】前記第２ロックモードは、バイトレンジロックに対する要
求に反応する請求項３４に記載の方法。
【請求項３８】前記第２ロックモードは、ＮＬＭファイルロックに対する
要求に反応する請求項３４に記載の方法。