ディレクトリメタデータをローカルにキャッシュするコンピュータが実行する方法であって、ディレクトリメタデータに対する第1の要求をアプリケーションから受け取るステップと、前記第1の要求を受け取ったことに応答して、前記ディレクトリメタデータに対する第2の要求をサーバに送信するステップであって、前記第2の要求が、前記ディレクトリメタデータを含むディレクトリへのハンドルに対する要求を含み、さらにディレクトリメタデータをローカルにキャッシュするためのリースに対する要求をも含み、前記リースが、前記サーバが前記リースを失効するまでディレクトリメタデータのローカルなキャッシュを可能とする、ステップと、第1の応答を前記サーバから受け取るステップであって、前記第1の応答が、前記ディレクトリメタデータおよび前記リースに対する前記要求の承認の指示を含む、ステップと、前記ディレクトリメタデータをローカルのキャッシュに格納するステップと、前記ディレクトリメタデータを前記アプリケーションに提供するステップとを含むことを特徴とする方法。前記ディレクトリメタデータに対する第3の要求を第2のアプリケーションから受け取るステップと、前記第3の要求を受け取ったことに応答して、前記ディレクトリメタデータを前記ローカルのキャッシュから提供するステップとをさらに含むことを特徴とする請求項1に記載の方法。前記第1の要求を受け取ったことに応答して、第1のディレクトリに関連付けられた第1のディレクトリ鍵、および前記第1のディレクトリを含む第2のディレクトリに関連付けられた第2のディレクトリ鍵を生成するステップと、前記第1のディレクトリ鍵および前記第2のディレクトリ鍵を、前記サーバに送信される前記第2の要求に含めるステップとをさらに含むことを特徴とする請求項1に記載の方法。前記第2のディレクトリ内に格納されたファイルを修正するための第3の要求を第2のアプリケーションから受け取るステップと、前記第3の要求を受け取ったことに応答して、前記ファイルに関連付けられたファイル鍵を生成するステップと、前記第3の要求からのデータ、前記ファイルに関連付けられた前記ファイル鍵、および前記第2のディレクトリ鍵とともに、第4の要求を前記サーバに送信するステップと、をさらに含むことを特徴とする請求項3に記載の方法。前記サーバから、前記リースの失効の通知を受け取るステップと、前記失効の通知を受け取ったことに応答して、前記失効の通知の受け取りの受理を送信するステップと、前記ディレクトリメタデータを前記ローカルのキャッシュから除去するステップとをさらに含むことを特徴とする請求項1に記載の方法。ディレクトリメタデータをローカルにキャッシュできるように構成されたコンピュータシステムであって、少なくとも1つのプロセッサと、前記少なくとも1つのプロセッサにより実行されたときに、サーバにおいてディレクトリメタデータに対する第1の要求を第1のクライアントから受け取るステップであって、前記第1の要求が、前記ディレクトリメタデータを含むディレクトリへのハンドルに対する要求を含み、さらにディレクトリメタデータをローカルにキャッシュするためのリースに対する要求をも含み、前記リースが、前記サーバが前記リースを失効するまでディレクトリメタデータのローカルなキャッシュを可能とする、ステップと、第1の応答を送信するステップであって、前記第1の応答が、前記ディレクトリメタデータおよび前記リースに対する前記要求の承認の指示を含む、ステップとを含む方法を実施する実行可能命令を格納したコンピュータ読取可能記憶媒体と、を備えることを特徴とするコンピュータシステム。前記方法が、第2の要求を受け取るステップと、前記第2の要求を第2のクライアントから受け取ったかどうかを判定するステップであって、前記第2の要求が前記ディレクトリメタデータを修正するステップと、をさらに含むことを特徴とする請求項6に記載のコンピュータシステム。前記判定するステップが、前記第2の要求からのディレクトリ鍵を、予め格納されたディレクトリ鍵と比較するステップを含むことを特徴とする請求項7に記載のコンピュータシステム。前記方法が、前記第2の要求からの前記ディレクトリ鍵が予め受け取ったディレクトリ鍵と同一でないと判定したことに応答して、失効通知を前記第1のクライアントに送信して前記リースを失効するステップをさらに含むことを特徴とする請求項8に記載のコンピュータシステム。前記方法が、前記第1の要求を受け取ったことに応答して、前記ディレクトリに対する前記ハンドルに関連付けられたファイル鍵を生成し、前記ディレクトリの親ディレクトリに関連付けられたディレクトリ鍵を生成するステップと、前記ファイル鍵および前記ディレクトリ鍵を、前記サーバに送信される前記第1の応答に含めるステップとをさらに含むことを特徴とする請求項6に記載のコンピュータシステム。添付図面を参照して様々な諸実施形態を以下でより完全に説明する。添付図面は本明細書の一部を構成し、本発明を実施するための具体的で例示的な諸実施形態を示す。しかし、諸実施形態を多数の様々な形態で実装してもよく、本明細書で説明した諸実施形態に限定されると解釈すべきではない。寧ろ、本開示が徹底的で完全であり、本発明の範囲を当業者に完全に伝達するように、これらの諸実施形態を提供するものである。諸実施形態を、方法、システム、または装置として実施してもよい。したがって、諸実施形態が、ハードウェア実装の形態、専らソフトウェア実装の形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実装の形態をとってもよい。したがって、以下の詳細な説明は限定的な意味で捉えるべきではない。図1は、諸実施形態を実装する分散ファイルシステム100の一実施形態を示す。システム100は、ファイルおよびファイル情報へのアクセスを必要とする様々なアプリケーションを実行する、クライアント102および104を含む。ファイルサーバ106はファイルおよびファイル情報を、例えばデータストア108に格納する。クライアント102および104は、ネットワーク、例えばネットワーク110を介してファイルサーバ106にアクセスすることができる。当業者が理解するように、ネットワーク110はLAN、WAN例えば、インターネット、記憶領域ネットワーク、またはクライアント102および104がファイルサーバ106と通信できるようにする他のネットワークであってもよい。分散ファイルシステム100は、クライアント102および104がファイルサーバ106にアクセスできるようにするためのプロトコルを実装してもよい。プロトコルの幾つかの非限定的な例には、SMBServerMessageBlock、SMB2、およびNFSがある。当業者が理解するように、ファイルアクセスプロトコルは、ファイルサーバにファイルを要求するための様々なフォーマットをクライアントに提供する。諸実施形態はどの特定のファイルアクセスプロトコルにも限定されない。寧ろ、説明する諸実施形態の特徴を任意のファイルアクセスプロトコルを用いて実装してもよい。当該ファイルアクセスプロトコルには、上で列挙したものが含まれるがこれらに限らない。一実施形態では、クライアント102および104がファイルサーバ106にリースを要求してもよい。当該リースにより、クライアント102および104はディレクトリメタデータをローカルにキャッシュすることができる。当業者が理解できるように、ファイルサーバ106が、実際のファイルデータを格納することに加えて、ディレクトリ内のファイルの特徴を記述するディレクトリメタデータを格納してもよい。例えば、ディレクトリメタデータとして、ディレクトリ内のファイルごとに、最終更新日付、作成日、ファイルサイズ、ファイルタイプ、および作成者名を含めてもよいがこれらに限らない。本実施形態を、リース機構を提供することによって実装することができる。図1に示すように、幾つかの実施形態では、クライアント102のようなクライアントが、メタデータリース要求を有するパケット112をファイルサーバ106に送信する。諸実施形態では、パケット112がリース要求に加えてメタデータの要求を含んでもよい。例えば、ブラウザアプリケーションのようなアプリケーションが、特定のディレクトリに対するディレクトリメタデータを要求してもよい。当該要求に応答して、クライアント102がパケット112を送信してもよい。当該パケット112は、特定のディレクトリのメタデータの要求ならびにメタデータリース要求を含む。図1に示すように、パケット112が読取リース、書込みリース、および/またはハンドルリースを指定してもよい。読取リースにより、クライアント102はディレクトリのメタデータをローカルのキャッシュに格納することができ、ブラウザアプリケーションがディレクトリメタデータを要求するたびにクライアントは当該要求をローカルのキャッシュから処理することができる。ハンドルリースにより、クライアント102は、ディレクトリハンドルを閉じるのを遅延させ、クライアント102がディレクトリハンドルを使用して、ブラウザアプリケーションならびにディレクトリに対するディレクトリメタデータを要求できる他のアプリケーションからの後の要求を処理できるようにすることができる。書込みリースにより、クライアントはアプリケーションがディレクトリメタデータに対して行った変更をキャッシュすることができる。図1に示す実施形態では、ファイルサーバ106が応答パケット114を送信する。当該応答パケット114は、要求されたディレクトリメタデータ、および要求されたリースが与えられたかどうかの指示を含む。応答パケットに基づいて、クライアント102はリース要求が与えられた場合はディレクトリメタデータをキャッシュし、当該ディレクトリメタデータをブラウザアプリケーションに提供する。リースが与えられなかったと応答パケットが示す場合は、クライアント102はディレクトリメタデータをキャッシュせず、単に当該ディレクトリメタデータをブラウザアプリケーションに提供する。クライアント102にリースが与えられなかった場合は、ディレクトリメタデータに対するブラウザアプリケーションからの任意の後の要求により、クライアントはディレクトリメタデータをファイルサーバ106に要求することとなる。下記でさらに詳細に説明するように、リースをクライアントに与えることにより、アプリケーションからの要求を処理する効率性がもたらされ、クライアントが複数の要求をファイルサーバ106に送信する必要性が減る。したがって、幾つかの実施形態では、ファイルサーバ106は一般に、衝突するリースを別のクライアントが現在保持していない限り、リースをクライアントに与える。ディレクトリメタデータの一貫性を保証するために、ファイルサーバ106は、特定のディレクトリメタデータに関して衝突するリースが別のクライアントに付与されないことを保証する。図1の説明は幾つかの実施形態の幾つかの特徴を導入するために与えたにすぎない。下記でさらに詳細に説明するように、他の実施形態では追加の特徴を提供してもよい。図1の説明は、他の任意の実施形態の範囲を限定するために使用されるべきではない。図2は、幾つかの実施形態で使用できるクライアントおよびサーバのブロック図を示す。上述のように、様々なファイルアクセスプロトコルを使用して、説明する実施形態の機能を実装することができる。以下の図2の説明のうち幾つかは、幾つかのSMB2の機能説明を含む。しかし、これは他の実施形態を限定するために使用されるべきではない。なぜならば、任意のファイルアクセスプロトコルを使用して、説明する機能を実装できるからである。SMB2の使用は一例にすぎず、例示の目的にのみ使用される。図2は、分散ファイルシステム200の一部であるクライアント202およびファイルサーバ204のブロック図を示す。幾つかの実施形態では、クライアント202をシステム100図1においてクライアント102および104として実装してもよく、ファイルサーバ204をシステム100図1においてファイルサーバ106として実装してもよい。図2に示すように、クライアント202は、サーバ204のファイルシステム208に格納されたファイルデータおよびメタデータへのアクセスを要求する、幾つかのアプリケーション206A乃至Cを含む。クライアント202はまた、リダイレクタ210を含む。一実施形態では、リダイレクタ210をSMB2リダイレクタとして構成してもよく、クライアント202およびサーバ204はSMB2プロトコルに従ってフォーマットされたパケットを用いて通信する。アプリケーション206A乃至Cのうち1つがサーバ204上に置かれたファイルを要求すると、リダイレクタ210がその要求を処理する。リダイレクタ210は、ファイルデータおよびメタデータに対する要求を有する、SMB2プロトコルに従ってフォーマットされたパケットを生成する。下記でさらに詳細に説明するように、諸実施形態では、SMB2プロトコルを拡張して、クライアント202がディレクトリメタデータをクライアント202上のローカルのキャッシュ212に格納できるようにするリース機構を提供する。当該リース機構は、サーバ204が与えるリースに関連付けられたリース鍵ディレクトリ鍵/ファイル鍵を格納する、クライアント202上の検索テーブル214を利用する。サーバ204はまた、リースを要求し当該リースを与えられるクライアントに対してリース鍵を格納する。サーバ204は、リーステーブル216を用いてリース鍵を格納する。システム200の動作の一例として、アプリケーション206Aはファイルシステム208のディレクトリ、例えばディレクトリ1に格納されたファイルに関するメタデータを要求することができる。その結果、アプリケーション206Aはリダイレクタ210が受け取る要求を発行する。当該要求を受け取ったことに応答して、リダイレクタ210は、ネゴシエート要求パケット218を送信することにより、サーバ204とのセッションを開始する。当業者が理解するように、ネゴシエート要求パケット218は、クライアントとサーバとの間でのセッションのネゴシエートを提供するSMB2プロトコルに従ってフォーマットされる。ネゴシエート要求パケット218は、クライアントがディレクトリメタデータのリースを処理できるか否かを示す情報を含む。一実施形態では、ディレクトリメタデータのリースを何らかのバージョンのSMB2プロトコルによってのみサポートしてもよく、ネゴシエート要求パケット218が、クライアントはメタデータのリースをサポートする或るバージョンのSMB2プロトコルをサポートしており、そのバージョンのSMB2プロトコルを用いてサーバと通信することを望むという指示を提供してもよい。ネゴシエート要求パケット218に応答して、サーバ204はネゴシエート応答パケット220を送信する。当該ネゴシエート応答パケット220は、サーバが当該バージョンのSMB2プロトコルをサポートするか否かの指示を含むことができる。現在の例では、ネゴシエート応答パケット220は、ディレクトリメタデータのリースをサポートする或るバージョンのSMB2プロトコルを用いて通信することにサーバが同意したことを示す。クライアント202とサーバ204との間のネゴシエーションが完了した後、リダイレクタ210は、アプリケーション206Aが要求しているディレクトリメタデータを要求することができる。一実施形態では、リダイレクタ210は先ず、要求されているディレクトリメタデータに関連付けられたディレクトリ鍵、例えば、ディレクトリ2鍵を生成する。さらに、リダイレクタ210はまた、要求されているディレクトリメタデータを含む親ディレクトリ、この場合はディレクトリ1に対する鍵を生成する。これらの鍵を検索テーブル214に格納する。図2の実施形態で示すように、検索テーブル214はディレクトリ鍵を、ディレクトリ内に格納されたファイルに対する様々なファイル鍵ならびにディレクトリ内のサブディレクトリに対するディレクトリ鍵に関連付ける。リース鍵は幾つかの実施形態ではGUIDgloballyuniqueidentifierである。しかし、当該リース鍵はGUIDには限定されない。リダイレクタ210は次に、ディレクトリ2内のディレクトリメタデータに対する要求を含み、ディレクトリ2内のディレクトリメタデータに対するリースもまた要求する、パケット222を送信する。リース要求の一部として、リダイレクタ210は、生成したリース鍵即ち、ディレクトリ1に対するディレクトリ鍵およびディレクトリ2に対するディレクトリ鍵を含む。別の実施形態では、リダイレクタ210は何らディレクトリ鍵を生成しない。その代わり、パケット222が、サーバがリース鍵を生成すべきであるとリダイレクタ210が示すことを規定する。サーバ204がディレクトリリース要求パケット222を受け取ると、サーバ204はディレクトリメタデータをディレクトリ2から取り出す。サーバ204はまた、サーバ204が要求されたリースをクライアント202に与えることができるか否かを判定する。具体的には、当該サーバは、自身が与えた他のリースに対するリース鍵ディレクトリ鍵およびファイル鍵を格納するリーステーブル216を参照することができる。本例では、以前にディレクトリ2に対するリースを要求したクライアントは存在せず、その結果、サーバ204は、ディレクトリ1に対するディレクトリ鍵およびディレクトリ2に対するディレクトリ鍵をディレクトリリース要求パケット222からリーステーブル216に格納する。当該サーバは、ディレクトリメタデータ、および要求されたリースが与えられたことの指示を有する、ディレクトリリース応答パケット224を送信する。この場合、要求されたリースが読取リース、書込みリース、および/またはハンドルリースを含んでもよい。リースが読取リースである場合、クライアント202はディレクトリ2のディレクトリメタデータに対するアプリケーション206Aからの要求を、キャッシュ212から処理することができる。リースが書込みリースである場合は、ディレクトリ2のディレクトリメタデータに対する任意の変更をキャッシュ212に格納することができる。リースがハンドルリースを含む場合は、クライアント202はアプリケーション206Aがハンドルを閉じるときにディレクトリ2に対するハンドルを閉じるのを遅延させることができる。次いで当該ハンドルを再利用して、アプリケーション206Aならびに他のアプリケーション206Bおよび206Cからの後の要求を処理することができる。リダイレクタ210はディレクトリメタデータをアプリケーション206Aに提供し、また当該ディレクトリメタデータをキャッシュ212に格納する。後の時点で、第2のクライアントがディレクトリ2に格納された同一のディレクトリメタデータに対するアクセスを要求した場合、サーバ204は、クライアント202に与えたハンドルリースと非互換のアクセスを第2のクライアントが要求した場合にクライアント202からのハンドルリースを失効することができる。サーバ204は、ハンドルリースが失効されていることを示す失効通知226をクライアント202に送信する。失効の後、アプリケーション206A、206B、および206Cからのディレクトリメタデータに対する任意の要求により、クライアント202は、新たなディレクトリハンドルを直接サーバ204に要求する必要があるはずである。幾つかの実施形態では、リースの失効が同期的に発生し、クライアント202は、失効通知を受け取ったという受理acknowledgment228を送信しなければならない。後の時点で第2のクライアントがディレクトリ2に格納されたディレクトリメタデータを修正すると、サーバ204は、クライアント202からの読取リースを失効することができ、これによりキャッシュ212に格納されたデータが無効invalidになる。失効の後は、アプリケーション206A、206B、および206Cからのディレクトリメタデータに対する任意の要求を、情報を直接サーバ204に要求することで処理しなければならない。当業者が理解するように、クライアント202はキャッシュ212内の情報を、さらにディレクトリメタデータをアプリケーション206A、206B、および206Cに提供する目的で使用することができる。一例として、ファイルがディレクトリに存在しない場合、アプリケーション206A、206B、および206Cからの見当たらないファイルに対する要求を、サーバ204に当該要求をリダイレクトする必要なしに失敗させることができる。これにより、存在しないファイルを対象としたオープンな要求に関するネットワークトラフィックを削減することを支援する。一実施形態では、上述のリース機能は過渡的である。即ち、リダイレクタ210はリースの取得と失効をローカルのアプリケーションに渡すことができる。次いで当該ローカルのアプリケーションを使用して他のリモートクライアントを処理することができる。このように、リースの付与および失効は原則として最終的なピアに対して過渡的である。図3乃至図6は、諸実施形態に従う動作フロー300、400、500、および600を示す。動作フロー300、400、500、および600を任意の適切なコンピューティング環境で実施してもよい。例えば、動作フローを、図1および図2に示すようなシステムにより実行してもよい。したがって、動作フロー300、400、500、および600の説明では、図1および図2のコンポーネントのうち少なくとも1つを参照することができる。しかし、図1および図2のコンポーネントに対する任意のかかる参照は説明の目的のためにすぎず、図1および図2の実装形態は動作フロー300、400、500、および600に関して非限定的な環境であることは理解されよう。さらに、動作フロー300、400、500、および600を逐次的に特定の順序で例示および説明するが、他の実施形態では、当該動作を異なる順序で、複数回、および/または並行して実施してもよい。さらに、幾つかの実施形態では1つまたは複数の動作を省略または組み合わせてもよい。図3は、幾つかの実施形態と整合する、ディレクトリメタデータをローカルにキャッシュするための動作フロー300を示す。フロー300は動作302で開始し、ディレクトリメタデータに対する要求ディレクトリメタデータの一部を含むをアプリケーションから受け取る。幾つかの実施形態では、動作302をクライアント上のリダイレクタが受け取る。当該リダイレクタは、システム100図1またはシステム200図2のような分散ファイルシステムの一部である。フロー300は、どの特定のファイルアクセスプロトコルを用いて実装することにも限定されない。任意の適切なファイルアクセスプロトコルを用いてフロー300の実施形態を実装してもよい。フローは動作302から判定304に移り、要求されたメタデータがローカルのキャッシュ内に格納されているか否かを判定する。判定304で、要求されたメタデータがローカルのキャッシュに格納されていると判定した場合は、フローは動作306に移り、当該メタデータを当該ローカルのキャッシュから取り出す。動作308で、当該ローカルのキャッシュから取り出した当該メタデータをアプリケーションに提供する。フロー300は310で終了する。一方、動作304で、ディレクトリメタデータがローカルのキャッシュに格納されていないと判定した場合は、制御は判定304から動作312に移り、当該ディレクトリメタデータにより特定されたファイルに対するディレクトリ鍵を生成する。幾つかの実施形態では、ディレクトリ鍵は、リダイレクタがフロー300を実行することにより生成したGUIDである。動作312の後、ディレクトリメタデータにより特定されたディレクトリの親ディレクトリに対するディレクトリ鍵を動作314で生成する。幾つかの実施形態では、動作314が当該ディレクトリの全ての先祖に対する鍵を生成することを含んでもよい。次いで当該鍵をローカルにキャッシュすることができる。動作316で、要求をファイルサーバに送信する。当該要求は、メタデータならびに、当該メタデータのローカルなキャッシュを可能とするリースに対するものである。動作318で、応答をファイルサーバから受け取る。当該応答は、諸実施形態では、要求されたリースがファイルサーバにより与えられたか否かの指示を含む。動作318からフローは動作320に移り、当該応答からのメタデータをアプリケーションに提供する。動作320に続いて、判定322で、サーバがディレクトリメタデータに関する要求されたリースを与えたか否かを判定する。判定322で、当該リースが承認されなかったと判定した場合は、メタデータをローカルにキャッシュすることはできず、フローは310で終了する。判定322で、リースがファイルサーバにより承認されたと判定した場合は、動作324でメタデータをローカルのキャッシュに格納する。動作324の後、フローは310で終了する。次に図4を参照すると、幾つかの実施形態と整合する、ディレクトリメタデータに関するハンドルリースを保持する分散ファイルシステムにアクセスするクライアントによりディレクトリメタデータを修正する要求を処理するためのフロー400が示されている。諸実施形態では、フロー400を、フロー300を実行した後に実行することができる。したがって、フロー400は、ハンドルリースがディレクトリメタデータをキャッシュするために与えられている諸実施形態において実施される。フロー400は動作402で開始し、ディレクトリメタデータを修正する要求を受け取る。当該要求は例えば、情報をファイルに書き込むための書込み要求であってもよく、これによりメタデータが変更される。非限定的な例では、当該メタデータには修正日、およびファイルサイズが含まれる。ディレクトリメタデータをキャッシュするためのハンドルリースを、ファイルサーバがフロー400を実行しているクライアントに予め与えている。動作404で、当該要求からの情報、即ちディレクトリメタデータ、例えばファイルへ書き込むべきデータを修正している情報を有するパケットを生成する。リースが予め与えられているので、第1のディレクトリ鍵および当該リースに関連付けられた親のディレクトリ鍵が存在する。したがって、動作406でディレクトリ鍵を当該パケットに含め、動作408で当該ディレクトリ鍵をパケットに含める。次いで410で当該パケットをサーバに送信する。幾つかの実施形態では、クライアントが最初に当該要求においてディレクトリ鍵および親のディレクトリ鍵を、オープンのために送信する。次いでサーバは、当該オープンに関する全ての後の動作に対して、当該鍵を使用する。しかし、他の実施形態では、クライアントが動作ごとに当該ディレクトリ鍵および親のディレクトリ鍵を提供してもよい。動作410の後、フローは動作412に移り、ローカルのキャッシュを更新して変更されたメタデータを反映する。換言すれば、ローカルのキャッシュを更新して、直近の修正日、ファイルサイズ等の変更を反映する。フロー400は414で終了する。図5は、ディレクトリメタデータに関する読取リースを失効する通知を処理するためのフロー500を示す。フロー500を、クライアントに読取リースがサーバ204図2のようなサーバから与えられた後に実行することができる。フロー500は動作502で開始し、ディレクトリメタデータに関して予め与えられた読取リースが失効していることを示す失効通知をサーバから受け取る。幾つかの実施形態では、キャッシュされたディレクトリメタデータ、例えば、ディレクトリ内のファイルの修正の一貫性に影響を及ぼす別のクライアントが実施した動作を理由として、失効通知をサーバが送信する。失効通知を受け取ったことに応答して、フロー500は動作504に移り、任意のキャッシュしたディレクトリメタデータを無効にする。幾つかの実施形態では、動作504は、ディレクトリメタデータを要求したアプリケーションに当該ディレクトリメタデータを提供するためにキャッシュを使用することがもはやできないことを示すための、クライアントが実施する幾つかのステップを含む。動作504の後、フローは動作506に移り、失効通知を成功裏に受け取ったという受理をサーバに送信する。幾つかの実施形態では、フロー500が動作506を含まなくともよい。これらの実施形態では、クライアントは失効通知を受け取り、サーバに受理を送信しない。次いでフローは動作508に移り、ディレクトリメタデータに対する任意の要求を、ディレクトリメタデータをサーバに要求することにより処理する。次いでフロー500は510で終了する。図6は、幾つかの実施形態と整合する、ディレクトリメタデータをローカルにキャッシュできるようにするための動作フロー600を示す。幾つかの実施形態では、フロー600を、分散ファイルシステムの一部であるファイルサーバにより実行することができる。フロー600は動作602で開始し、ディレクトリメタデータおよびリースに対する要求を受け取る。幾つかの実施形態では当該要求を、クライアント、または分散ファイルシステムの一部であるクライアント上のリダイレクタが送信する。動作602の後、フロー600は判定604に移り、動作602で受け取った要求において要求されたようにリースを与えるか否かの判定を行う。判定604が幾つかの要因に基づいてもよい。当該要因には、例えばリースが当該ディレクトリメタデータに対して既に与えられたか否かが含まれる。判定604で、リースを与えないと判定した場合は、フローは動作606に移り、ディレクトリメタデータを有するパケットを送信する。当該パケットは、要求されたリースが与えられなかったという指示を含む。次いでフローは動作608で終了する。判定604で、リースを与えることができると判定した場合、フロー600は動作610に移り、ディレクトリ鍵および親のディレクトリ鍵を格納する。幾つかの実施形態では、ディレクトリ鍵および親のディレクトリ鍵は、クライアントに与えたリースを追跡し続けるためのリース鍵として使用されるGUIDである。幾つかの実施形態では、動作602で、ディレクトリ鍵および親のディレクトリ鍵を、ディレクトリメタデータおよびリース要求とともに受け取る。本実施形態では、ディレクトリ鍵および親のディレクトリ鍵は、動作602で要求を送信したクライアントが生成している。他の実施形態では、動作610で、ディレクトリ鍵および親のディレクトリ鍵を当該サーバが生成して、これらをリーステーブルに格納してもよい。幾つかの実施形態では、ディレクトリ鍵および親のディレクトリ鍵は2つ以上のオープンなハンドルの間のコンテナと子の関係を表現する。同じことがファイル鍵およびディレクトリ鍵に当てはまる。当該ファイル鍵は、ディレクトリ内のファイルに関連付けられている。例えば、2つのオープンなハンドルH1およびH2が存在すると仮定する。H1をファイル鍵=K1およびディレクトリ鍵=Dに関連付けてもよい。H2をファイル鍵=K2およびディレクトリ鍵=Dに関連付けてもよい。これらの鍵は、これらのハンドルが参照するファイルが同一のディレクトリ内に存在することを示す。図6を再度参照すると、動作612で、要求されたディレクトリメタデータ、およびリースの承認の指示を有する応答パケットをクライアントに送信する。次いでクライアントは、与えられたリースと整合するディレクトリメタデータをローカルにキャッシュすることができる。動作614で、ディレクトリメタデータを修正する要求を受け取る。当該要求は例えば、追加の情報をファイルに書き込むためのものであってもよい。これにより、例えば最終更新時刻、またはファイルサイズを変更することでディレクトリメタデータが修正される。フローは動作614から判定616に移り、ディレクトリメタデータを修正する要求がリース保持者leaseholderからのものであるか否かを判定する。一実施形態では、判定616で行う判定が、ディレクトリメタデータを修正する動作が行われたハンドルに関連付けられたリース鍵と、予めクライアントに提供されたハンドルに関連付けられたリース鍵とを比較することによって行われる。上述のように、幾つかの実施形態では、クライアントがファイルハンドルまたはディレクトリハンドルに関連付けられたリース鍵を生成し、したがって、各鍵は特定のクライアントに対して一意である。一例では、クライアントに提供されたハンドルH1はファイル鍵=K1およびディレクトリ鍵=Dに関連付けられる。後にサーバが、ハンドルH2に関連付けられたメタデータを修正する動作を受け取った場合、当該サーバはハンドルH2に関連付けられたリース鍵をハンドルH1に関連付けられたリース鍵と比較する。例えばH2がファイル鍵=K2およびディレクトリ鍵=Dに関連付けられている場合、当該サーバは、H1およびH2に対するディレクトリ鍵が同一であるため、ディレクトリDに関するリースを有する同一のクライアントが当該修正を行い、したがって当該リースを失効する必要がないと判定する。一方、H2がファイル鍵=K2およびディレクトリ鍵=D1に関連付けられている場合は、サーバは、ハンドルH1およびとH2に関連付けられたディレクトリ鍵が異なるので、リースを失効しなければならないと判定する。リース保持者がディレクトリメタデータに対する修正を行ったものであると判定した場合は、フローは動作618に移り、ファイルシステムを更新して修正されたディレクトリメタデータを反映する。次いでフロー600は608で終了する。動作616で、要求がリース保持者からのものでないと判定した場合は、フローは判定620に移り、要求された修正が、別のクライアントに与えたリースと不整合であるかどうかを判定する。当該要求が不整合でない場合は、フローは動作618に移り、608で終了する。判定620で、要求がリースと不整合であると判定した場合は、フローは動作622に移り、ディレクトリメタデータに関するリースを現在保持しているクライアントに失効通知を送信する。当該失効は、当該ディレクトリメタデータにアクセスする全てのクライアントの間でディレクトリメタデータの一貫性を保持するために送信されるものである。動作624で失効通知の受理を受け取り、その後、フローは動作618に移り608で終了する。図7は一般的なコンピュータシステム700を示す。当該コンピュータシステム700を使用して本明細書に記載の諸実施形態を実装することができる。コンピュータシステム700はコンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用範囲または機能範囲に関して何ら限定を示唆しようとするものではない。また、コンピュータシステム700が、例示的なコンピュータシステム700で示したコンポーネントのどの1つまたは組合せに関してどのような依存性または要件も有すると解するべきではない。幾つかの実施形態では、システム700を、図1および図2に関して上述したクライアントおよび/またはサーバとして使用してもよい。その最も基本的な構成では、システム700は一般に少なくとも1つの処理装置702およびメモリ704を備える。コンピューティング装置の厳密な構成および種類に応じて、メモリ704はRAMのような揮発性、ROM、フラッシュメモリ等のような不揮発性、またはこれらの何らかの組合せであってもよい。この最も基本的な構成を図7で点線706により示す。システムメモリ704は、システム700上で実行されているアプリケーションを格納する。例えば、メモリ704は図2に関して上述したレポート検索テーブル214を格納してもよい。本明細書で使用するコンピュータ読取可能媒体という用語には、コンピュータ記憶媒体を含めてもよい。コンピュータ記憶媒体には、コンピュータ読取可能命令、データ構造、プログラムモジュール、または他のデータのような情報を記憶するための任意の方法または技術で実装した、揮発性および不揮発性、取外し可能および取外し不能な媒体を含めてもよい。システムメモリ704、取外し可能記憶装置および取外し不能記憶装置708は全て、コンピュータ記憶媒体の例である即ち、メモリ記憶装置。コンピュータ記憶媒体には、RAM、ROM、EEPROMelectricallyerasableread-onlymemory、フラッシュメモリもしくは他のメモリ技術、CD-ROM、DVDdigitalversatilediskもしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または情報の格納に使用できコンピューティング装置700がアクセス可能な他の任意の媒体を含めてもよいが、これらに限らない。任意のかかるコンピュータ記憶媒体が装置700の一部であってもよい。コンピューティング装置700はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置等のような入力装置複数可714を有してもよい。ディスプレイ、スピーカ、プリンタ等のような出力装置複数可716を含めてもよい。上述の装置は例であり、他のものを使用してもよい。本明細書で使用するコンピュータ読取可能媒体という用語には、通信媒体を含めてもよい。通信媒体を、コンピュータ読取可能命令、データ構造、プログラムモジュール、または、搬送波もしくは他の伝送機構のような変調データ信号における他のデータで具体化してもよく、また通信媒体には任意の情報伝達媒体を含む。変調データ信号という用語は、1つまたは複数の特性集合を有するかまたは当該信号内の情報をエンコードするように変化した信号を言い表すことができる。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続のような有線媒体、ならびに、音響、RFradiofrequency、赤外線、および他の無線媒体のような無線媒体を含んでもよい。本明細書では一実施形態または実施形態と言及するが、これは、説明した具体的な機能、構造、または特徴が少なくとも1つの実施形態に含まれることを意味する。したがって、かかる語句を使用することで、単に1つの実施形態より多くの実施形態に言及することができる。さらに、説明した機能、構造、または特徴を1つまたは複数の実施形態において任意の適切な方法で組み合わせてもよい。しかし、本発明を1つまたは複数の具体的な詳細なしに、または、他の方法、リソース、材料等を用いて実施してもよいことは当業者には理解されよう。他の事例では、公知の構造、リソース、または動作については詳細に図示も説明もしていないが、これは本発明の諸態様を不明瞭にするのを避けるためにすぎない。例示的な諸実施形態および適用事例を例示および説明したが、本発明は上述の厳密な構成およびリソースに限定されないことは理解されよう。特許請求する発明の範囲から逸脱しない当業者に明らかな様々な修正、変更、および変形を、本明細書で開示した方法およびシステムの配置構成、動作、および詳細において行ってもよい。