(57)【要約】      （修正有）【課題】同一のマルチプロトコルロックマネージメントシステムを用いて、複数のさまざまなファイルサーバプロトコルを正しく相互利用を行うための方法およびシステムを提供する。【解決手段】いずれかのクライアントデバイスがデータにアクセスする、またはロックを獲得する前に、始めのクライアントデバイスがいずれのクライアントデバイスであっても、さらに現在のロックに対して始めのファイルサーバプロトコルまたはファイルロッキングプロトコルがいずれのプロトコルであっても、ファイルサーバは、いずれかのクライアントデバイスが獲得していようとしているロックが現在のロックと矛盾していないかどうか判定する。【選択図】図２
2008305405.tif 000002
【特許請求の範囲】
【請求項１】
複数のさまざまなファイルサーバまたはファイルロッキングプロトコルを用いて、複数のクライアントデバイスにおいて同一のファイルロッキングセマンティクスを実施するステップを含むファイルサーバを操作する方法。
【請求項２】
前記同一のファイルロッキングセマンティクスは、オパチュニスティックロックを含み、
オパチュニスティックロックは、第１プロトコルを用いる第１クライアントデバイスによって要求され、
前記オパチュニスティックロックをブレークすることは、前記第１プロトコルとは異なる第２プロトコルを用いる第２クライアントデバイスによって生じることを特徴とする請求項１に記載の方法。
【請求項３】
前記第１プロトコルは、ＣＩＦＳを含む請求項２に記載の方法。
【請求項４】
前記第２プロトコルは、ＮＦＳまたはＮＬＭを含む請求項２に記載の方法。
【請求項５】
前記同一ファイルロッキングセマンティクスは、
選択されたファイルに関するオパチュニスティックロックを、前記第１プロトコルを用いる第１メッセージに応じて、前記第１クライアントデバイスに与えるステップと、
前記第２プロトコルを用いる第２メッセージに応じて、前記オパチュニスティックロックをブレークするステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記ブレークするステップは、
前記第２メッセージに応じて、アップロックブレークメッセージを前記第１クライアントデバイスに送信するステップと、
前記第２メッセージによって指示されるファイルシステム要求の実行を遅らせるステップと、
前記アップロックブレークメッセージに対する応答を前記第１クライアントデバイスから受け取るステップと、
前記の受け取るステップの後、前記第２メッセージを処理し、前記第２メッセージに対して応答するステップと
を含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記同一ファイルロッキングセマンティクスは、チェンジモニタリングロックを含み、チェンジモニタリングロックは、
第１プロトコルを用いる第１クライアントデバイスによって要求されることができるタイプであり、
チェンジ通知が、前記第１プロトコルとは異なる第２プロトコルを用いる第２クライアントデバイスによって生じるタイプである
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記第１プロトコルが、ＣＩＦＳを含む請求項７に記載の方法。
【請求項９】
前記第２プロトコルが、ＮＦＳを含む請求項７に記載の方法。
【請求項１０】
前記同一のファイルロッキングセマンティクスが、
前記第１プロトコルを用いる第１メッセージに応じて、選択されたディレクトリに関するチェンジモニタリングロックを前記第１クライアントデバイスに与えるステップと、
前記選択されたディレクトリに関する、前記第２プロトコルを用いる第２メッセージに応じて、チェンジ通知メッセージを前記第１クライアントデバイスに送信するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記の実施するステップは、複数のさまざまなプロトコルを認識するステップと、
少なくとも前記プロトコルの１つを用いるメッセージに応じて、同一ファイルロッキングセマンティクスを規定するステップと、
前記クライアントデバイス全てに対して前記同一のファイルロッキングセマンティクスを実施するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記同一のファイルロッキングセマンティクスは、
前記第１プロトコルを用いる第１メッセージに応じて、オパチュニスティックロックを前記第１クライアントデバイスに与えるステップと、
前記第２プロトコルを用いる第２メッセージに応じて、前記オパチュニスティックロックをブレークするステップと
を含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記のブレークするステップは、前記第２メッセージに応じて、アップロックブレークメッセージを前記第１クライアントデバイスに送信するステップと、
前記第２メッセージによって指定されるファイルシステム要求の実行を遅らせるステップと、
前記アップロックブレークメッセージに対する応答を、前記第１クライアントデバイスから受け取るステップと、
前記の受け取るステップの後、前記第２メッセージを処理し、前記第２メッセージに対して応答するステップと
を含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記同一のファイルロッキングセマンティクスを実施するステップは、
前記第１プロトコルを用いる第１クライアントデバイスからの第１メッセージに応じて、チェンジモニタリングを承諾するステップと、
前記第２プロトコルを用いる第２メッセージに応じて、チェンジ通知メッセージを前記第１クライアントデバイスに送信するステップと、
を含むことを特徴とする請求項１１に記載の方法。
【請求項１５】
前記同一のファイルロッキングセマンティクスを実施する前記のステップは、
前記同一のファイルロッキングセマンティクスを妨害しようとする選択されたメッセージを認識するステップと、
前記選択されたメッセージと関連付けられたプロトコルに適したエラー応答とともに、前記選択されたメッセージに対して応答するステップと
を含むことを特徴とする請求項１１に記載の方法。
【請求項１６】
前記同一のファイルロッキングセマンティクスを実施するステップは、
前記の選択されたプロトコルにおいて、ファイルに関するバイトレンジロックを獲得するための選択されたメッセージを認識するステップと、
獲得する前記バイトレンジロックが、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かテストするステップとを含み、
前記バイトレンジロックは、ロックタイプを有することを特徴とする請求項１１に記載の方法。
【請求項１７】
前記同一のファイルロッキングセマンティクスを実施するステップは、
前記選択されたプロトコルにおいて、ファイルをオープンするための選択されたメッセージを認識するステップを含み、前記選択されたメッセージは要求されたアクセスモードを含み、
前記同一のファイルロッキングセマンティクスを実施するステップは、さらに前記要求されたアクセスモードを用いてオープンする前記ファイルが、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かをテストするステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１８】
前記選択されたメッセージは、要求されたディナイモードを含み、
前記要求されたディナイモードを用いるオープンする前記ファイルが、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かをテストするステップを含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記同一のファイルロッキングセマンティクスを実施する前記ステップは、
前記の選択されたプロトコルにおいて、ファイルから読み出すための、またはファイルに書き込むための選択されたメッセージを認識するステップと、
ファイルからの読み出しが、またはファイルへの書きこみが、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かテストするステップと
を含むことを特徴とする請求項１１に記載の方法。
【請求項２０】
前記の実施するステップは、第１プロトコルを用いる第１メッセージを受け取るステップと、
第２プロトコルを用いる第２メッセージを受け取るステップと、
前記第２メッセージによって要求される前記アクセスを前記ロックと比較し、前記アクセスが前記ロックによって禁じられているならば、前記アクセスを拒否するステップとを含み、
前記第１メッセージは、選択されたファイルの少なくとも一部をロックするように作用し、前記第２メッセージは、前記一部へのアクセスを要求するように作用することを特徴とする請求項１に記載の方法。
【請求項２１】
前記第１プロトコルは、ＣＩＦＳを含む請求項２０に記載の方法。
【請求項２２】
前記第１プロトコルまたは前記第２プロトコルは、ＮＬＭを含む請求項２０に記載の方法。
【請求項２３】
前記第２プロトコルは、ＮＦＳを含む請求項２０に記載の方法。
【請求項２４】
前記第２メッセージを受け取る前記ステップは、ファイルに関するバイトレンジロックを獲得するための前記第２メッセージとして、前記第２プロトコルを用いる前記第２メッセージを受け取るステップを含み、前記バイトレンジロックはロックタイプを有し、
前記比較するステップは、獲得する、前記ロックタイプを有する前記バイトレンジロックが、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かをテストするステップを含む請求項２０に記載の方法。
【請求項２５】
前記テストするステップは、前記第２メッセージに使用されるプロトコルに反応する請求項２４に記載の方法。
【請求項２６】
前記テストするステップは、前記第１プロトコルに対してはファイルオープン時に作用し、前記第２プロトコルに対してはアクセス時に作用する請求項２４に記載の方法。
【請求項２７】
前記テストするステップは、前記第１プロトコルに対してはファイルオープン時に作用し、前記第２プロトコルに対してはロック要求時に作用する請求項２４に記載の方法。
【請求項２８】
前記第２メッセージを受け取る前記ステップは、ファイルをオープンするための、前記第２プロトコルを用いる前記第２メッセージを認識するステップを含み、前記第２メッセージは、要求されたアクセスモードを含み、
前記比較するステップは、前記要求されたアクセスモードを用いて、アクセスする前記ファイルは、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かをテストするステップを含む請求項２０に記載の方法。
【請求項２９】
前記第２メッセージを受け取る前記ステップは、ファイルから読み出すためのまたはファイルへ書き込むための、前記第２プロトコルを用いる第２メッセージを認識するステップを含み、
前記の比較するステップは、前記第２メッセージによってアクセスしようとする前記ファイルが、同一または他のプロトコルを用いるメッセージによって作成された既存のロックと矛盾するか否かテストするステップを含む請求項２０に記載の方法。
【請求項３０】
前記第１メッセージを受け取る前記ステップは、前記第１メッセージに応じて、アパチュニスティックロックを承諾するステップを含み、
前記の比較するステップは、前記第２メッセージに応じて、前記アパチュニスティックロックをブレークするステップを含む請求項２０に記載の方法。
【請求項３１】
前記のブレークするステップは、前記第２メッセージに応じて、アップロックブレークメッセージを前記第１クライアントデバイスに送信するステップと、
前記第２メッセージによって指定されるファイルシステム要求の実行を遅らせるステップと、
前記アップロックブレークメッセージに対する応答を前記第１クライアントデバイスから受け取るステップと、
前記の受け取るステップの後、前記第２メッセージを処理し、前記第２メッセージに対して応答するステップと
を含むことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記アップロックブレークメッセージに対する前記応答は、アップロックブレークアクノリッジメントメッセージまたはファイルクローズメッセージを含む請求項３１に記載の方法。
【請求項３３】
前記ファイルロッキングセマンティクスは、第１プロトコルを用いる第１クライアントデバイスによって要求されるアクセスモードとディナイモードとに応じて決定されるロックモードを含む請求項１に記載の方法。
【請求項３４】
前記ファイルロッキングセマンティクスは、
第１プロトコルを用いる第１クライアントデバイスによって要求されるアクセスモードとディナイモードとに応じて決定される第１ロックモードと、
前記第１プロトコルとは異なる第２プロトコルを用いる第２クライアントデバイスからのメッセージに応じて決定される第２ロックモードとを含み、
前記ファイルサーバは、前記第１ロックモードと前記第２ロックモードとの比較に反応することを特徴とする請求項１に記載の方法。
【請求項３５】
前記比較は、ロック互換性マトリックスを含む請求項３４に記載の方法。
【請求項３６】
前記比較は、ロック変換マトリックスを含む請求項３４に記載の方法。
【請求項３７】
前記第２ロックモードは、バイトレンジロックに対する要求に反応する請求項３４に記載の方法。
【請求項３８】
前記第２ロックモードは、ＮＬＭファイルロックに対する要求に反応する請求項３４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチプロトコルファイルサーバにおけるロッキングに関するものである。
【背景技術】
【０００２】
統合されたコンピュータネットワークにおいて、複数のクライアントデバイスがファイルを共有することが好ましい。１つの既知の方法は、それら複数のクライアントデバイスからのファイルサーバ要求を受け取りかつ応答できるネットワークファイルサーバを、ファイルを記憶するために設けることである。これらのファイルサーバ要求は、ファイルサーバプロトコルを用いて作成される。このファイルサーバプロトコルは、ファイルサーバとクライアントデバイスの両方によって認識され順守されている。ファイルはファイルサーバに記憶されているので、複数のクライアントデバイスが、ファイルに対して同時にアクセスすることができる。
【０００３】
この技術分野における１つの問題は、複数のさまざまなファイルサーバプロトコルがあることである。それぞれは、ファイルオペレーションに対して異なるセマンティクスを有する。１つのファイルサーバが複数のファイルサーバプロトコルを認識するようにできることが知られているが、多くのファイルサーバプロトコルは、ファイルロッキングおよびファイル共有に関して、異なりかつ互換性のないセマンティクスを有するので、特に困難である。互換性のないロッキングセマンティクスは、複数のさまざまなクライアントデバイスにおいて、１つのファイルシステムを規定する障害となる。第１クライアントデバイスが第１ファイルサーバプロトコル（第１ファイルロッキングセマンティクス）に依存するならば、第２ファイルサーバプロトコル（第２ファイルロッキングセマンティクス）を用いる第２クライアントデバイスは、第１ファイルクライアントデバイスにおけるアプリケーションが完全に作動しなくなるようにするかもしれない。したがって、各ファイルサーバプロトコルの正しいオペレーションは、他の全てのファイルサーバプロトコルによるファイルロッキングセマンティクスが一致するかどうかに左右される。
【０００４】
例えば、ＵＮＩＸオペレーティングシステム（またはその変形）を用いるデバイスで一般的に使用されるプロトコルは、ＮＦＳ（ネットワークファイルシステム(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)）を指定することができる。それ以後、ＣＩＦＳファイルシステムオペレーションは、オープンされているファイルに対するアクセスモードをチェックすることだけが必要である。ＣＩＦＳクライアントデバイス１３０は、クライアントデバイス１３０がオープンしているファイルにおけるバイトレンジに対してバイトレンジロックを指定することもできる。バイトレンジロックは、「ライトロック」（リードライトのアクセスモードと、ディナイオールのディナイモードとを有する）と呼ばれる排他的ロックか、「リードロック」（リードオンリーのアクセスモードと、ディナイライトのディナイモードとを有する）と呼ばれる非排他的ロックかのいずれかである。
【００２４】
ファイルサーバ１１０は、アクセスモードとディナイモードを組み合わせるロックモードを決定する。ここにおいて使用されているように、「ロックモード」という用語は、ファイルサーバ１１０によって設定された、アクセスモードとディナイモードとを組み合わせる同一のロックモードを表している。
【００２５】
ファイルオープン時に、ＣＩＦＳクライアントデバイス１３０は、アップロック（オパチュニスティックロック）を獲得することもできる。アップロックは、ファイルをオープンするＣＩＦＳクライアントデバイス１３０は、別のクライアントデバイス１３０がそのファイルを利用しようとしない限りファイルに対する排他的なアクセス権を有することを規定する。アップロックは、アップロックの排他性が他のクライアントデバイス１３０のアクセスによってブレークされるという警告のために、クライアントデバイス１３０が必要としている以上のファイルに対する排他性を規定する。
【００２６】
ファイルサーバ１１０は、ＮＦＳ（付属プロトコルＮＬＭありもしくは付属プロトコルＮＬＭなし）またはＣＩＦＳを用いて、複数のクライアントデバイス１３０間の正しい相互利用を規定する。正しく相互利用するために、ファイルサーバ１１０は、同一ファイルロッキングセマンティクスを規定する。好ましい実施の形態において、同一ファイルロッキングセマンティクスは以下の効果を有する。
【００２７】
ファイルサーバ１１０は、ＣＩＦＳクライアントによってオープンされかつ使用されている、ディナイライトまたはディナイオール等のディナイモードであるファイル１１３におけるデータに対して、Ｕｎｉｘクライアントデバイス２０１が上書きするＮＦＳライトオペレーションを実行することを防ぐ。
【００２８】
ファイルサーバ１１０は、Ｕｎｉｘクライアントデバイス２０１およびＰＣ ＮＦＳ Ｗｉｎｄｏｗｓクライアントデバイス２０２が、ＣＩＦＳクライアントによってオープンされかつ使用されているファイル１１３を除去するまたは改名するというＮＦＳファイルシステムオペレーションを実行することを防ぐ。
【００２９】
Ｕｎｉｘクライアントデバイス２０１またはＰＣ ＮＦＳ Ｗｉｎｄｏｗｓクライアントデバイス２０２が、ＣＩＦＳクライアントデバイスによってアップロックされたファイル１１３に対してデータを書きこむ、ファイル１１３を除去するまたはファイル１１３の名前を変えるために、ＮＦＳ要求を作成するとき、ファイルサーバ１１０は、ファイル１１３にＣＩＦＳアップロックセマンティクスを実施する。ファイルサーバ１１０は、アップロックブレークメッセージ１４０を、アップロックを保持するクライアントデバイス１３０に送信し、クライアントデバイス１３０から応答を受け取る。クライアントデバイス１３０がファイル１１３を閉じるならば、ＮＦＳ要求は続行し、ファイルサーバ１１０はそれを許可する。
【００３０】
Ｕｎｉｘクライアントデバイス２０１またはＰＣ ＮＦＳ Ｗｉｎｄｏｗｓクライアントデバイス２０２が、ＣＩＦＳクライアントデバイスによってアップロックされたファイル１１３からデータを読み出すために、ＮＦＳ要求を作成するとき、ファイルサーバ１１０は、ファイル１１３に対してＣＩＦＳアップロックセマンティクスを実施する。ファイルサーバ１１０は、アップロックブレークメッセージ１４０を、アップロックを保持するクライアントデバイス１３０に送信し、クライアントデバイス１３０から応答を受け取る。クライアントデバイス１３０がファイル１１３を閉じるか、またはファイルのライトキャッシュをファイルサーバ１１０に書きこむときに、ＮＦＳ要求は続行し、ファイルサーバ１１０はそれを許可する。
【００３１】
ファイルサーバ１１０は、特定のロックモードに関して、ＣＩＦＳ Ｗｉｎｄｏｗｓクライアントデバイス２０３からのファイルオープン要求と、ＰＣ ＮＦＳ Ｗｉｎｄｏｗｓクライアントデバイス２０２からのＮＬＭファイルロック要求とに対する互換性をテストする。ＮＬＭ「ファイルロック」という用語は、ここでは、以下の書類において記載されるＮＬＭ「シェアーロック」という既知の用語の代わりに使用される。その書類は、Ｘ／Ｏｐｅｎ ＣＡＥ 仕様書、Ｘ／Ｏｐｅｎ相互作用プロトコル、ＸＮＦＳ第４版（Ｘ／Ｏｐｅｎドキュメント番号Ｃ２１８）であり、本明細書に完全に記載されているように参照として本明細書に含まれている。特定のロックモードは、要求されたアクセスモードおよびディナイモードを組み合わせることにより、ファイルサーバ１１０によって決定される。
【００３２】
これらの効果を生じさせるために、ファイルサーバ１１０は、以下のファイルロックマネージメントオペレーションを実行する。
【００３３】
ＣＩＦＳファイルオープン要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、現在のＣＩＦＳおよびＮＬＭファイルロックと矛盾し、かつ既存のＮＬＭバイトレンジロックと矛盾するファイルオープン要求をテストする。新しく要求されたファイルロックと比較するために、ファイルサーバ１１０は、現在のＮＬＭバイトレンジロックを、ディナイノンのディナイモードを有するものとして、また非排他性ロックであるリードオンリーのアクセスモードと排他性ロックであるリードライトのアクセスモードとを有するものとして扱う。
【００３４】
ＣＩＦＳバイトレンジロック要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、現在のＣＩＦＳおよびＮＬＭバイトレンジロックと矛盾するバイトレンジロック要求をテストする。
【００３５】
ＮＬＭバイトレンジロック要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、現在のＣＩＦＳおよびＮＬＭバイトレンジロックと矛盾し、かつ現在のＣＩＦＳファイルロックと矛盾するバイトレンジロック要求をテストする。
【００３６】
ＰＣ ＮＦＳ クライアントデバイス１３０（ファイルオープン要求メッセージ１４０をシミュレートするために使用される）からのＮＬＭファイルロック要求メッセージ１４０を受け取る際に、ファイルサーバ１１０は、既存のＣＩＦＳおよびＮＬＭファイルロックとは相容れず、かつ既存のＮＬＭバイトレンジロックとは相容れないＮＬＭファイルロック要求をテストする。新たに要求されたＮＬＭファイルロックと比較するために、ファイルサーバ１１０は、既存のＮＬＭバイトレンジロックを、ディナイノンのディナイモードを有するものとして、また非排他性ロックであるリードオンリーのアクセスモードと、排他性ロックであるリードライトのアクセスモードとを有するものとして扱う。
【００３７】
オペレーション方法（マルチプロトコルファイルサーバ）
図３は、マルチプロトコルファイルサーバを操作する方法のプロセスフローチャートを示す。
マルチプロトコルファイルサーバの操作方法３００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。
【００３８】
フローポイント３１０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０を受け取れる状態にある。
【００３９】
ステップ３１１において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０を受け取り、解析する。ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０がＮＦＳファイルサーバプロトコル、ＮＬＭファイルロッキングプロトコル、ＣＩＦＳファイルロッキングプロトコルのいずれを使用するか判定する。ファイルサーバ要求メッセージ１４０が、ＮＦＳファイルサーバプロトコル、またはＮＬＭファイルロッキングプロトコルを使用するならば、方法３００は、ステップ３１２に続く。ファイルサーバリクエスト要求メッセージ１４０が、ＣＩＦＳファイルサーバプロトコルを使用するならば、方法３００は、ステップ３１３に続く。
【００４０】
ステップ３１２において、ファイルサーバ１１０は、要求メッセージ１４０がファイルシステムオペレーション（データの読み出しもしくは書き込み、またはディレクトリの変更等）を実行するためのＮＦＳファイルサーバ要求を含む。その代わりとして、ファイルサーバ１１０は、要求メッセージ１４０がＮＬＭバイトレンジロックを獲得するためのＮＬＭファイルロッキング要求を含む。どちらのケースにおいても、方法３００は、フローポイント３２０に続く。
【００４１】
ステップ３１３において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０がＣＩＦＳのリードもしくはライトオペレーションを実行することか、ＣＩＦＳバイトレンジロックを獲得することか、またはＣＩＦＳファイルオープンオペレーションを実行することか判定する。ファイルサーバ要求メッセージ１４０が、ＣＩＦＳバイトレンジロックを獲得することであるか、またはＣＩＦＳファイルオープンオペレーションを実行することであるならば、方法３００は、フローポイント３２０に続く。ファイルサーバ要求メッセージ１４０が、ＣＩＦＳのリードもしくはライトオペレーションを実行することであれば、方法はフローポイント３３０に続く。ファイルサーバ要求メッセージ１４０が、ＣＩＦＳ「チェンジ通知」要求であるならば、方法は、フローポイント３５０に続く（チェンジ通知要求は、図６の説明とともにさらに記載される）。
【００４２】
フローポイント３２０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０によって要求されたオペレーションとファイル１１３のファイルロッキングステータスとを比較できる状態にある。ファイル１１３のファイルロッキングステータスは、ファイル１１３に対する現在のファイルロックおよびバイトレンジロックを含む。
【００４３】
ステップ３２１において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０が対象にしているファイル１１３を判断し、このファイル１１３がアップロックされているかどうか判定する。ファイル１１３がアップロックされているならば、方法３００は、ステップ３２２に続く。ファイル１１３がアップロックされていないならば、方法３００は、ステップ３２３に続く。
【００４４】
ステップ３２２において、ファイルサーバ１１０は本明細書に記載されているようにアップロックをブレークする。ステップ３２２の実行は、図５についての説明でさらに記載される。アップロックをブレークさせることによって、ファイル１１３のファイルロッキングステータスを変化させることが可能である。
【００４５】
ステップ３２３において、ファイルサーバ１１０は、同一のファイルロッキングセマンティクスを用いて、要求されたオペレーションとファイル１１３のファイルロッキングステータスを比較する。このステップにおいて、要求されたオペレーションは、ＮＦＳの読み出しもしくは書き込みオペレーション、ＮＦＳもしくはＣＩＦＳのディレクトリ変更オペレーション、ＮＬＭのファイルロックもしくはバイトレンジロックを獲得しようとする試み、ＣＩＦＳファイルオープンオペレーションであってもよい。ステップ３２３の動作と、同一のファイルロッキングセマンティクスは、図４の説明とともにさらに記載される。この比較は、要求されたオペレーションが許容できることを示すならば、方法３００は、ステップ３２４に続く。要求されたオペレーションが許容できないのであれば、方法３００はステップ３２５に続く。
【００４６】
ステップ３２４において、ファイルサーバ１１０は、要求されたオペレーションを実行する。方法３００はフローポイント３４０に続く。
【００４７】
ステップ３２５において、ファイルサーバ１１０は、要求されたオペレーションの実行を拒絶し、エラーメッセージを伴ってクライアントデバイス１３０に対して応答する。方法３００は、フローポイント３４０に続く。
【００４８】
フローポイント３３０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０によって要求されたオペレーションと、ファイル１１３のファイルロッキングステータスと比較できる状態にある。
【００４９】
フローポイント３５０において、ファイルサーバ１１０は、本明細書に記載されているように、チェンジ通知オペレーションを実行できる状態にある。
【００５０】
ステップ３５１において、第１のＣＩＦＳクライアントデバイス１３０は、ディレクトリに対するファイルロックを要求し（ディレクトリをオープンするためにファイルシステム要求メッセージ１４０を用いて）、ディレクトリに対するファイルロックを、ディレクトリに関するチェンジモニタリングロックに変換する。このステップ３５１の実行は、図６の説明とともにさらに記載される。
【００５１】
フローポイント３４０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０に対して応答し、方法３００は、ファイルサーバ要求メッセージ１４０について完了する。
【００５２】
オペレーション方法（クロスプロトコルロックマネージャ）
図４は、マルチプロトコルファイルサーバにおけるクロスプロトコルロックマネージャを操作する方法のプロセスフローチャートを示す。
【００５３】
マルチプロトコルファイルサーバにおけるクロスプロトコルロックマネージャを操作する方法４００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。
【００５４】
フローポイント４１０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０における要求されたオペレーションを、ファイル１１３のファイルロッキングステータスと比較できる状態にある。
【００５５】
ファイルサーバ１１０は、同一のファイルロッキングセマンティクスを使用して、どのファイルサーバプロトコルで要求されたオペレーションのファイルロッキング状態でも同じ方法で作成する。同一のファイルロッキングセマンティクスは、同一の複数のファイルロックを識別する。それぞれのファイルロックは、要求しているクライアントデバイス１３０に対するアクセスモードと、全ての他のクライアントデバイス１３０に対するディナイモードとを含む。
【００５６】
好ましい実施の形態において、アクセスモードは、リードオンリー、ライトオンリー、またはリードライトの３つの可能性のうちの１つである。同様に、好ましい実施の形態において、ディナイモードは、ディナイノン、ディナイリード、ディナイライト、ディナイオールの４つの可能性のうちの１つである。
【００５７】
第１クライアントデバイス１３０がファイル１１３に対するファイルロックを獲得した後、第２クライアントデバイス１３０によって要求されかつファイルサーバ１１０によって決定されたロックモードが、ファイル１１３のファイルロッキングステータスと互換性があるならば、第２クライアントデバイス１３０は、ファイル１１３だけにアクセスすることができる。例えば、第１クライアントデバイス１３０は、ファイル１１３に対するディナイライトのディナイモードを有するファイルロックを獲得することができる。第２ＮＦＳクライアントデバイス１３０は、ファイル１１３に対して書き込もうとすることもできるし、または第２ＣＩＦＳクライアントデバイス１３０は、ライトアクセスを含むアクセスモードで、ファイル１１３をオープンしようとすることもできる。いずれもケースにおいても（ファイル１１３に対するファイルロックが、本明細書に記載されているように、アパチュニスティックロックでないならば）、ファイルサーバ１１０は、第２クライアントデバイス１３０による要求を拒否する。
【００５８】
本明細書に示されているように、ファイルサーバ１１０は、第２クライアントデバイス１３０によって使用されるファイルサーバプロトコルに応じて、たびたび第２クライアントデバイス１３０によって要求されるアクセスとファイルロックとの比較を実行する。
【００５９】
第２クライアントデバイス１３０が、ＣＩＦＳファイルサーバプロトコルを使用してファイル１１３をオープンするならば、ファイルサーバ１１０は、ファイルオープン時にファイル１１３のファイルロッキングステータスをチェックする。
【００６０】
第２クライアントデバイス１３０が、ＮＦＳファイルサーバプロトコルを使用してファイル１１３に対する読み出しまたは書きこみを実行するならば、実際にファイルシステムオペレーションを実行するときに、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスをチェックする。これは、ファイル１１３を動かす、移動させる、またはファイル１１３の名前を変える等のオペレーションのように、第１クライアントデバイス１３０の対象領域からファイルを移動させる影響を有するファイルシステムオペレーションにも当てはまる。
【００６１】
第２クライアントデバイス１３０がＣＩＦＳファイルサーバプロトコルを使用してバイトレンジロックを要求するならば、バイトレンジロックが要求されたときに、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスと、他のＣＩＦＳまたはＮＬＭバイトレンジロックとが矛盾しているかチェックする。バイトレンジロックが要求されたときに、ファイルサーバ１１０は、バイトレンジロックと他のＣＩＦＳファイルロックとが矛盾しているかチェックしない。それは、バイトレンジロックと他のＣＩＦＳファイルロックとが矛盾しているかは、ファイルオープン時にチェックされたからである。
【００６２】
第２クライアントデバイス１３０がＮＬＭプロトコルを使用してバイトレンジロックを要求するならば、バイトレンジロックが要求されたときに、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスが、現在のＣＩＦＳまたはＮＬＭバイトレンジロックと矛盾しているか、また現在のＣＩＦＳファイルロックと矛盾しているかチェックする。
【００６３】
ステップ４２１において、ファイルサーバ１１０は、ファイル１１３と関連するファイルロックがすでに１つ以上あるかどうか判断する。ファイルロックが１つ以上あるならば、方法４００は、ステップ４２２に続く。ファイルロックが１つ以上ないならば、方法は、ステップ４１１に続く。
【００６４】
ステップ４２２において、ファイルサーバ１１０は、ファイル１１３に関するファイルロックをファイル１１３に関する１つの同等のファイルロックに併合する。このステップ４２２を実行するために、すでに存在しているファイルロックが１つにまとめられるまで、ファイルサーバ１１０は、すでに存在しているファイルロックと追加するファイルロックとを表１において相互参照する。
【００６５】
表１は、１つにまとめられたファイルロッキングセマンティクスを用いて、マルチプロトコルファイルサーバにおけるロック変換表を示す。
【００６６】
【表１】
2008305405.tif 000003
ロック変換マトリックス
Ａ＝アクセスモード（Ｒ＝リード、Ｗ＝ライト、ＲＷ＝リードライト、ＡＮＹ＝Ｒ、Ｗ、ＲＷのいずれか）
Ｄ＝ディナイモード（ＤＮ＝ディナイノン、ＤＲ＝ディナイリード、ＤＷ＝ディナイライト、ＤＡ＝ディナイオール）
【００６７】
ステップ４１１において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０において要求されたオペレーションの種類を判断する。要求されたオペレーションがＣＩＦＳファイルオープンオペレーションであるならば、方法４００は、ステップ４２３に続く。要求されたオペレーションがＮＦＳファイルサーバオペレーションであるならば、方法４００は、ステップ４３１に続く。要求されたオペレーションが、バイトレンジロックについてのＣＩＦＳ要求またはＮＬＭ要求であるならば、ファイルシステム１１０は、ステップ４４１に続く。
【００６８】
ステップ４２３において、ファイルサーバ１１０は、ファイル１１３に関するファイルロックと、第２クライアントデバイス１３０によって要求されたファイルオープンとを比較する。このステップ４２３を実行するために、ファイルサーバ１１０は、すでに存在するファイルロックと、新しく要求されたアクセスモードおよびディナイモードとを表２において相互参照し、対応する表のエントリーに応じて新しく要求されたアクセスモードおよびディナイモードを許可するか、または拒否する。
【００６９】
ファイルサーバ１１０が、新しく要求されたアクセスモードおよびディナイモードを許可するならば、方法４００は、ステップ４２４を実行する。ファイルサーバ１１０が、新しく要求されたアクセスモードおよびディナイモードを拒否するならば、方法４００は、ステップ４２４を実行しない。
【００７０】
表２は、１つにまとめられたファイルロッキングセマンティクスを用いて、マルチプロトコルファイルサーバにおいて試行されたファイルロックの相互参照を示す。
【００７１】
【表２】
2008305405.tif 000004
【００７２】
表２において示されているように、すでに存在しているファイルロックと、新しく要求されたアクセスモードおよびディナイモードとの各ペアは、対応する決定を備えている。その決定により、新しく要求されたアクセスモードおよびディナイモードが拒否されるか、または許可される。
【００７３】
ファイルサーバ１１０は、現在のＣＩＦＳファイルロックと、ファイルオープンオペレーションを実行するための新しい要求との間の矛盾をチェックするならば、現在のＣＩＦＳファイルロックは、新しいファイルオープン要求において要求されたアクセスモードおよびディナイモードについて相互参照される。
【００７４】
ファイルサーバ１１０は、現在のファイルロックと、ファイルのリードオペレーションまたはライトオペレーションを実行するための新しいＮＦＳ要求との間の矛盾をチェックするならば、集合体ロックモード（現在のファイルロックの組み合わせ）は、新しい要求を実行するために必要とされるアクセスモードについて相互参照される。
【００７５】
ファイルサーバ１１０は、現在のファイルロックまたはバイトレンジロックと、ＮＬＭバイトレンジロックに対する新しい要求との間の矛盾をチェックするならば、現在のファイルロックとバイトレンジロックは、新しいＮＬＭバイトレンジロック要求と同等のロックモードについて相互参照される。現在のファイルロックを比較するために、ファイルサーバ１１０は、新たに要求されたＮＬＭバイトレンジロックを、ディナイノンのディナイモードを有するものとして、さらに非排他性ロック（「リードロック」とも呼ばれる）の場合、リードオンリーのアクセスモードを、排他性ロック（「ライトロック」とも呼ばれる）の場合、リードライトのアクセスモードを有するものとして扱う。既存のバイトレンジロックと比較するために、ファイルサーバ１１０は、新たに要求されたＮＬＭバイトレンジロックを、リードロックの場合、リードオンリーのアクセスモードとディナイライトのディナイモードとを有するものとして、さらにライトロックの場合、リードライトのアクセスモードとディナイオールのディナイモードとを有するものとして扱う。
【００７６】
次に、方法４００は、フローポイント４５０に続く。
【００７７】
ステップ４３１において、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスを、第２クライアントデバイス１３０によって要求されたオペレーションと比較する。このステップ４３１を実行するために、ファイルサーバ１１０は、ファイルロックに関するディナイモードと要求されたオペレーションとを比較し、その比較に応じて要求されたオペレーションを許可するか、または拒否する。
【００７８】
次に、方法４００は、フローポイント４５０に続く。
【００７９】
ステップ４４１において、ファイルサーバ１１０は、ファイル１１３のファイルロッキングステータスを、第２クライアントデバイス１３０によって要求されたＮＬＭバイトレンジロックと比較する。好ましい実施の形態において、ＣＩＦＳバイトレンジロック要求は、バイトレンジロックのみについてチェックされる。それは、それらが以前のＣＩＦＳファイルオープンオペレーションを必要とし、現在のファイルロックは、以前のＣＩＦＳファイルオープンオペレーションのときに、すでにチェックされているからである。このステップ４４１を実行するために、ファイルサーバ１１０は、以前から存在するファイルロッキングステータスと要求されたバイトレンジロックを表３において相互参照し、対応する表エントリーに応じて要求されたバイトレンジロックを許可するか、または拒否する。
【００８０】
ファイルサーバ１１０が、新しく要求されたＮＬＭバイトレンジロックを許可するならば、方法４００は、ステップ４４２を実行する。ファイルサーバ１１０が、新しく要求されたバイトレンジロックを拒否するならば、方法４００は、ステップ４４２を実行しない。
【００８１】
表３は、１つにまとめられたファイルロッキングセマンティクスを用いて、マルチプロトコルファイルサーバにおける新たに要求されたＮＬＭバイトレンジロックと現在のファイルロックとの相互参照を示す。
【００８２】
【表３】
2008305405.tif 000005
【００８３】
表３において示されているように、既存のファイルロックと新たに要求されたＮＬＭバイトレンジロックの各ペアは、対応する決定を備えている。その決定により、新しく要求されたバイトレンジロックが拒否されるか、または許可される。
【００８４】
ステップ４４２において、ファイルサーバ１１０は、新しい追加のバイトレンジロックとして新しく要求されたバイトレンジロックとファイル１１３を関連付ける。
【００８５】
方法４００は、フローポイント４５０に続く。
【００８６】
フローポイント４５０において、ファイルサーバ１１０は、ファイルサーバ要求メッセージ１４０において要求されたオペレーションと、ファイル１１３のファイルロッキングステータスを比較し、要求されたオペレーションを許可するか、または拒否する。
【００８７】
オペレーション方法（アップロックマネージャ）
図５は、マルチプロトコルファイルサーバにおけるアップロックマネージャを操作する方法のプロセスフローチャートを示す。
【００８８】
マルチプロトコルファイルサーバにおけるアップロックマネージャを操作する方法５００は、本明細書において記載されているように、複数のプロセスステップとフローポイントを含む。これらのプロセスステップとフローポイントは、少なくとも１つのクライアントデバイス１３０とともにファイルサーバ１１０によって実行される。
【００８９】
アップロックは、Ｗｉｎｄｏｗｓオペレーティングシステム環境におけるファイルロッキングの分野において知られている。アップロックは、ワシントン州レドモンドにあるマイクロソフト社(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を含んでおり、本明細書において全部記載されているように参照によって本明細書に含まれる。
【０１１７】
フローポイント６３０において、ファイルサーバ１１０は、指定されたディレクトリに関する変化を第１ＣＩＦＳクライアントデバイス１３０に通知し、次のメッセージ１４０に対して準備する。
【０１１８】
別の実施の形態
本明細書には好ましい実施の形態が開示されているが、多くの変形例が本発明の概念、範囲、精神内にある可能性があるものであり、これらの変形例は、本明細書を精読すれば当業者には明らかになるであろう。
【０１１９】
技術的な付録
本発明に関するその他の情報、また更なる情報は、本明細書とともに記載された技術的な付録において含まれる。この技術的な付録は、３０ページ（図面を含む）を含み、本明細書に全部記載されたように、参照によって含まれる。
【図面の簡単な説明】
【０１２０】
【図１】マルチプロトコルファイルサーバを含むシステムの第１のブロック図を示す。
【図２】マルチプロトコルファイルサーバを含むシステムの第２のブロック図を示す。
【図３】マルチプロトコルファイルサーバを操作する方法のプロセスフローチャートを示す。
【図４】マルチプロトコルファイルサーバにおけるクロスプロトコルロックマネージャを操作する方法のプロセスフローチャートを示す。
【図５】マルチプロトコルファイルサーバにおけるアップロックマネージャを操作する方法のプロセスフローチャートを示す。
【図６】マルチプロトコルファイルサーバにおけるチェンジ通知マネージャを操作する方法のプロセスフローチャートを示す。
【符号の説明】
【０１２１】
１００  ファイルサーバ、    １１１  プロセッサ、    １１２  大容量記憶装置、    １２０  ネットワーク、    １３０  クライアントデバイス。
【図１】
2008305405.tif 000006
【図２】
2008305405.tif 000007
【図３】
2008305405.tif 000008
【図４】
2008305405.tif 000009
【図５】
2008305405.tif 000010
【図６】
2008305405.tif 000011
【手続補正書】
【提出日】平成20年7月2日(2008.7.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチプロトコルファイルサーバにより、前記マルチプロトコルファイルサーバにより具体化される複数のさまざまなファイルロッキングプロトコルを用いる１組のクライアントデバイスの間でユニフォームロッキングセマンティクスを強制することを実行する方法であって、
第１ロッキングプロトコルを用いて、選択されたデータセットに関するオパチュニスティックロックを第１クライアントデバイスに与えるステップと、
第２のクライアントデバイスが、前記第１ロッキングプロトコルと異なる第２プロトコルを用いて、選択された前記データセットへのアクセスを要求するとき、選択された前記データセットに関する前記オパチュニスティックロックをブレークするステップと、
選択された前記データセットに関するロッキングステータスを、前記ユニフォームロッキングセマンティクスを用いて生成するステップであって、前記複数のさまざまなファイルロッキングプロトコルの中の異なるファイルロッキングプロトコルにおいて現存しているファイルロックを結合することを含むステップと、
要求された前記アクセスを前記ロッキングステータスと比較するステップと、
要求された前記アクセスと前記ロッキングステータスの間に矛盾がないならば、選択された前記データセットへの、要求された前記アクセスを与えるステップと
からなる方法。
【請求項２】
前記生成ステップは、ロック互換性マトリックスを使用する請求項１に記載の方法。
【請求項３】
前記比較ステップは、ロック変換マトリックスを使用する請求項１に記載の方法。
【請求項４】
前記ユニフォームロッキングセマンティクスは、アクセスタイプを特定するアクセスモードと、アクセスタイプをディナイするディナイモードとからなる請求項１に記載の方法。
【請求項５】
前記ブレークするステップは、さらに、
アップロックブレークメッセージを前記第１クライアントデバイスに送信するステップと、
前記アップロックブレークメッセージへの応答が第１クライアントデバイスから受け取られるまで、要求されたオペレーションの実行を遅らせるステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項６】
複数のさまざまなファイルロッキングプロトコルを具体化するマルチプロトコルファイルサーバであって、
大容量記憶装置と、
ネットワークへのインタフェースと、
前記複数のさまざまなファイルロッキングプロトコルを用いる１組のクライアントデバイスにより前記インタフェースを介して前記大容量記憶装置にアクセスするためのユニフォームロッキングセマンティクスを強制するプロセッサとからなり、
前記プロセッサは、
第１ロッキングプロトコルを用いて、選択されたデータセットに関するオパチュニスティックロックを第１クライアントデバイスに与える第１承諾手段と、
第２のクライアントデバイスが、前記第１ロッキングプロトコルと異なる第２プロトコルを用いて、選択された前記データセットへのアクセスを要求するとき、選択された前記データセットに関する前記オパチュニスティックロックをブレークするブレーク手段と、
選択された前記データセットに関するオパチュニスティックロックを、前記ユニフォームロッキングセマンティクスを用いて生成する手段であって、前記複数のさまざまなファイルロッキングプロトコルの異なるファイルロッキングプロトコルの中で現存しているファイルロックを結合することにより生成する生成手段と、
要求された前記アクセスを前記ロッキングステータスと比較する比較手段と、
要求された前記アクセスと前記ロッキングステータスの間に矛盾がないならば、選択された前記データセットへの、要求された前記アクセスを与える第２承諾手段とを含む、
マルチプロトコルファイルサーバ。
【請求項７】
前記生成手段はロック互換性マトリックスを使用する請求項６に記載のマルチプロトコルファイルサーバ。
【請求項８】
前記比較手段はロック変換マトリックスを使用する請求項６に記載のマルチプロトコルファイルサーバ。
【請求項９】
前記ユニフォームロッキングセマンティクスは、アクセスタイプを特定するアクセスモードと、アクセスタイプをディナイするディナイモードとからなる請求項６に記載のマルチプロトコルファイルサーバ。
【請求項１０】
前記ブレーク手段は、さらに、
アップロックブレークメッセージを前記第１クライアントデバイスに送信する送信手段と、
前記アップロックブレークメッセージへの応答が第１クライアントデバイスから受け取られるまで、要求されたオペレーションの実行を遅らせる遅延手段と
を含むことを特徴とする請求項６に記載のマルチプロトコルファイルサーバ。