JP6835968B2 - スタビングによるコンテンツ記憶の最適化 - Google Patents

Description

本開示は、コンピューティングデバイス上にデータを格納する技術分野に関する。

スタブファイルは第１の記憶位置に記憶されているようにユーザまたはアプリケーションに見えるコンピュータファイルまたは他のデータオブジェクトであってもよいが、ファイルのコンテンツは実際には全体的に、または部分的に、異なる記憶位置に記憶されてもよい。したがって、ユーザまたはアプリケーションがスタブファイルにアクセスすることによってファイルのコンテンツにアクセスしようとするとき、アクセス要求はインターセプト（傍受）され、ファイルのコンテンツは、実際の記憶位置から取り出される。一例として、従来のファイルスタビングは、特定のファイルコンテンツのための第１の記憶位置と第２の記憶位置との間の１対１の関係を表すために使用されてきた。

いくつかの実施形態は、クライアントデバイス上にスタブファイルを作成することと、スタブファイルのコンテンツを、ネットワークを介してストレージに格納することとを含む。クライアントデバイス上のスタブファイルのメタデータは、本明細書で説明する技法によって最新の状態に維持することができる。一例として、クライアントデバイスはネットワークを介してサービスコンピューティングデバイスに、クライアントデバイスに関連するファイルシステムへの変更に関連する情報の要求を送信してもよい。それに応答して、クライアントデバイスはサービスコンピューティングデバイスから、ファイルシステムに対する１つまたは複数の変更のリストを受信してもよい。クライアントデバイスは、受信した１つまたは複数の変更のリストに少なくとも部分的に基づいて、クライアントデバイス上のスタブファイルのメタデータを追加および／または更新してもよい。場合によっては、スタブファイルがクライアントデバイス上のローカルストレージに格納されたスタブデータ構造を含んでもよい。また、スタブファイルに対応するファイルのファイルコンテンツを、ネットワークを介してストレージに格納してもよい。

詳細な説明は、添付の図面を参照して述べられる。図において、参照番号の左端の数字は、参照番号が最初に現れる図を識別する。異なる図における同じ参照番号の使用は、同様のまたは同一のアイテムまたは特徴を示す。

図１は、いくつかの実施形態に係るスタビングを行うコンテンツストレージを提供するように構成されたシステムの論理構造の一例を示す。

図２は、いくつかの実施形態に係るスタブデータ構造の一例を示す。

図３は、いくつかの実施形態によるトークンデータ構造の一例を示す。

図４は、いくつかの実施形態に係る、クライアントデバイスデータを更新するためのプロセス例を示す流れ図である。

図５は、いくつかの実施形態に係る、クライアントがファイルシステムに対する変更についてトランザクションクエリエンジンに問合わせるプロセス例を示す流れ図である。

図６は、いくつかの実施形態に係る、スタブファイルのメタデータを作成および／または更新するための例示的なプロセスを示す流れ図である。

図７は、いくつかの実施形態に係る、スタブファイルを作成するためのプロセス例を示す流れ図である。

図８は、いくつかの実施形態に係る、リモート更新に基づいてスタブファイル情報を更新するためのプロセス例を示す流れ図である。

図９は、いくつかの実施形態に係る、リモートで作成されたファイルのためのスタブファイルを作成するためのプロセス例を示す流れ図である。

図１０は、いくつかの実施形態に係る、スタブファイルがリモートで削除されるプロセス例を示す流れ図である。

図１１は、いくつかの実施形態に係る、データをミラーリングするためのプロセス例を示す流れ図である。

図１２は、いくつかの実施形態に係る、サービスコンピューティングデバイス（複数可）およびストレージの構成例を示す。

図１３は、いくつかの実施形態に係るクライアントデバイスの構成例を示す。

本明細書のいくつかの実施形態は、ファイルおよびデータストレージを管理するための技術および構成を対象とする。一例として、クライアントデバイスはサービスコンピューティングデバイスと通信してもよく、クライアントデバイスのうちのいくつかはいくつかのユーザファイルのスタブファイルメタデータのみを格納してもよく、一方、これらのファイルのファイルメタデータおよびファイルコンテンツの両方はクライアントデバイスのうちのいくつかの他のものおよびサービスコンピューティングデバイス上に格納してもよい。ユーザまたはアプリケーションがスタブファイルのファイルコンテンツにアクセスしようとするとき、ファイルコンテンツは、サービスコンピューティングデバイスから直にダウンロードしてもよい。さらに、スタブファイルメタデータが各ファイルの最新のバージョンおよび条件を反映するように、複数のクライアントデバイスにわたってファイルを同期させてもよい。したがって、個々のクライアントデバイス上の記憶容量は個々のクライアントデバイス上のいくつかのファイルのみのファイルコンテンツを記憶することによって管理されてもよく、一方、すべてのファイルのファイルコンテンツはサービスコンピューティングデバイス上に記憶される。

場合によっては、通知サービスを、リスニング側クライアントに記憶位置に対する特定の変更のための変更通知イベントを提供することができるサービスコンピューティングデバイス上で実行可能なプログラムとしてもよい。さらに、トランザクションクエリエンジンはサービスコンピューティングデバイス上で実行可能なプログラムであってもよく、サービスコンピューティングデバイスは特定の期間にわたって記憶位置に対して生じるファイル変更トランザクションの時間順リストを要求側クライアントに提供することができる。トランザクションクエリエンジンは、スタブファイルのメタデータを更新するためのファイルシステム変更情報を提供することによって、スタブファイルデータのローカル仮想表現を最新に維持するプロセスを実行してもよい。さらに、データ同期サービスは通知サービスからの変更通知を登録し、変更通知に基づいてトランザクションクエリエンジンからの更新を要求することを、クライアントコンピューティングデバイス上で実行可能なプログラムとしてもよい。

いくつかの例では、コンテンツデータの大部分がネットワーク記憶位置に格納されていても、低ストレージ空間環境で実行されているクライアントが格納されている情報の完全な仮想ビューをクライアントデバイス上に提示することができる。例えば、本明細書のシステムは、クライアントデバイスが必要に応じてローカルアクセスのためにオフロードされたファイルコンテンツを容易に呼び出すことができる。さらに、本明細書の通知サービス、トランザクションクエリエンジン、およびデータ同期サービス処理を有するシステムは、共有ファイルシステムに参加するすべてのクライアントデバイスが１つまたは複数の他のクライアントデバイスからの修正にもかかわらず、ファイルシステムの最新のビューを維持することを可能にしてもよい。

場合によっては、通知サービスは、カーソルとして働くトークンを使用して、サービスコンピューティングデバイスと１つまたは複数のクライアントデバイスとの間で定義される特定のストレージセット、たとえばファイルシステムの変更を追跡してもよい。このファイルシステムは、特定のクライアントデバイスに対して私的であってもよく、複数のクライアントデバイス間で共有されてもよい。各クライアントデバイスは、そのトークンを使用してファイルシステムイベントを追跡してもよい。サービスコンピューティングデバイスによって受信されたファイルシステムの変更は、サービスコンピューティングデバイスに、ファイルシステムのためにサービスコンピューティングデバイスによって使用されるトークンを変更させてもよい。トークン交換を使用して、クライアントデバイスは、クライアントデバイスが登録された関心を有するファイルシステムに何らかの変化があった場合に通知されてもよい。通知サービスはクライアントデバイスに関連するファイルシステムへの変更がサービスコンピューティングデバイスで受信されたことを１つまたは複数の登録されたクライアントデバイスに報告することができるが、通知サービスは実際の変更を特定のファイルシステムに報告しなくてもよい。

クライアントデバイス上で実行されるデータ同期サービスは、登録されたファイルシステムに影響を及ぼすファイルシステム変更イベントの通知を受信するために、通知サービスに登録してもよい。通知サービスがクライアントデバイスに関連するファイルシステムに未処理の変更があることを報告すると、クライアントデバイス上のデータ同期サービスは、トランザクションクエリエンジンに要求を送信して、特定の変更のリストを取り出してもよい。トランザクションクエリエンジンは特定の変更のリストを決定し、要求しているクライアントデバイスに送信する。トランザクションクエリエンジンは、トークンを使用して、対応するファイルシステムのイベントを追跡してもよい。クライアントデバイスはクライアントデバイスのトークンが最後に更新されてから１つまたは複数の指定されたファイルシステムで発生した変更をトランザクションクエリエンジンが返すという要求と共に、その最も最近に受信されたトークンを送信してもよい。これにより、クライアントデバイスは、クライアントデバイスが以前に認識していないファイルシステムイベントのみを処理することができる。クライアントデバイス上のデータ同期サービスは、クライアントデバイス上のローカル構成に基づいて、トランザクションクエリエンジンによって報告された変更のリストを処理してもよい。この処理はミラー構成のためのファイルコンテンツをダウンロードすること、スタブ構成のためのスタブメタデータを作成または更新すること、または特定のファイルがサービスコンピューティングデバイスから除去された場合に、ファイルデータおよび／またはスタブメタデータのローカル表現を完全に除去することを含んでもよい。

本明細書の実施形態は、クライアントデバイス上に存在するスタブファイルメタデータが例えば、多対１クライアントデバイス対サービスコンピューティングデバイス関係の状況において、サービスコンピューティングデバイスによって維持されるファイルのネットワークストレージバージョンと更新され、同期されることを可能にする。例えば、いくつかの例は、サービスコンピューティングデバイスに存在するデータが共有ファイルシステムに基づいて複数のクライアントデバイスにわたって等しく共有され得る環境を含む。したがって、任意のクライアントデバイスは、データを変更することを許可されてもよく、結果として生じる変更はスタブファイルのそれらのそれぞれのローカル仮想表現が変更に応答して最新のままであるように、それぞれの通知を受信するデータを共有するすべてのクライアントデバイスにおいてそれらのローカルスタブファイル状態を更新することをもたらしてもよい。

本明細書のファイルスタブ技術のいくつかの例では、ファイルデータがクライアントデバイス上のオリジナルファイルのローカルでコンパクトな表現を維持しながら、１つのサービスコンピューティングデバイスまたはネットワーク記憶位置から別のサービスコンピューティングデバイスに再配置されてもよく、その結果、ファイルコンテンツは要求された場合に、サービスコンピューティングデバイスからクライアントデバイスに容易かつシームレスに呼び戻されてもよい。本明細書の例は、複数のクライアントがローカルポリシーによって定義されたローカルデータを自由に表すことができる。例えば、第１クライアントデバイスはミラーリングポリシーを使用するように構成されてもよく、その結果、サービスコンピューティングデバイス上のファイルのコンテンツに対する変更は第１クライアントデバイスに直ちに呼び出され、一方、第２クライアントデバイスはファイルに対するスタビングポリシーを使用するように構成されてもよく、その結果、サービスコンピューティングデバイス上のファイルのコンテンツに対する変更は実際のファイルデータが第２クライアントデバイスに送信されることなく、スタブファイルメタデータが第２クライアントデバイス上で更新される。さらに、任意の単一のクライアントデバイスはそのデータビューを区分してもよく、その結果、クライアントデバイスは、ミラーリングされたデータとスタブデータの両方を同じクライアントデバイス上でインタリーブすることができる。例えば、ストレージ管理者は、性能上の理由から特定のクライアントに常駐（すなわち、ピン止め）されたままであるように特定のデータセットにフラグをたてることを選択してもよい一方で、あまり頻繁にアクセスされないデータをスタブファイルとして維持させるようにしてもよい。さらに、クライアントデバイスは、非同期モードまたは同期モードのいずれかで動作するように構成されてもよい。

場合によっては、クライアントデバイスとサービスコンピューティングデバイスとの間の通信がＲＥＳＴ(representational state transfer)ベースのＡＰＩ(アプリケーションプログラムインターフェース）または他のデータＡＰＩを介して実行されてもよい。サービスコンピューティングデバイスは、クライアント動作モードを含むことができるデータＡＰＩを介してクライアントデバイスの動作モードを検出してもよい。いくつかの例では、サービスコンピューティングデバイスは、２ノード構成でセットアップしてもよく、したがって、常にオンラインとすることができる。サービスコンピューティングデバイスは、ストレージエリアネットワーク、クラウドストレージ、または他のネットワークベースのストレージなどを介して、クライアントデバイスデータを格納するためにバックエンドストレージをさらに採用してもよい。

説明のために、いくつかの例示的な実施形態が、１つまたは複数のネットワーク記憶位置、およびファイルおよび他のデータのストレージを管理するための複数のクライアントデバイスと通信する１つまたは複数のサービスコンピューティングデバイスの環境で説明される。しかし、本明細書の実施形態は提供される特定の例に限定されず、本明細書の開示に照らして当業者には明らかであるように、他のタイプのコンピューティングシステム構成、他のタイプのストレージ環境、他のタイプのクライアント構成、他のタイプのデータオブジェクトなどに拡張することができる。

図１は、いくつかの実施形態による、データオブジェクトおよび関連するメタデータを格納するように構成されたシステム１００の論理構成例を示す。システム１００は、１つまたは複数のネットワーク１０５などを介してストレージ１０４と通信することができるか、または他の方法でストレージ１０４に接続することができる１つまたは複数のサービスコンピューティングデバイス１０２を含む。さらに、サービスコンピューティングデバイス１０２は、１つまたは複数のネットワーク１０６を介して、１つまたは複数のユーザ１１０に関連付けることができるクライアントコンピューティングデバイス１０８（１）、１０８（２）、１０８（３）．．（以下、「クライアントデバイス」）などの１つまたは複数のクライアントコンピューティングデバイス１０８と通信することができるようにしてもよい。この例では、第１クライアントデバイス１０８（１）および第２クライアントデバイス１０８（２）が第１ユーザ１１０（１）に関連付けられ、第３クライアントデバイス１０８（３）が第２ユーザ１１０（２）に関連付けられていると仮定する。さらに、この例では３つのクライアントデバイス１０８および２つのユーザ１１０が示されているが、他の例では任意の数のクライアントデバイス１０８および関連するユーザ１１０が存在してもよい。

１つまたは複数のネットワーク１０５および１０６は、インターネットなどの広域ネットワーク、イントラネットなどのローカルエリアネットワーク（ＬＡＮ）、セルラーネットワークなどのワイヤレスネットワーク、Ｗｉ−Ｆｉおよび／またはＢＬＵＥＴＯＯＴＨ（登録商標）などの短距離ワイヤレス通信などのローカルワイヤレスネットワーク、ファイバチャネル、光ファイバ、イーサネット、または任意の他のそのようなネットワークを含む有線ネットワーク、直接有線接続、または前述のもの任意の組合せを含む、任意の適切なネットワークを含んでもよい。したがって、１つまたは複数のネットワーク１０５および１０６は有線および／または無線通信技術の両方を含むことができ、いくつかの例では、ネットワーク１０５および１０６が同じ１つまたは複数のネットワークを含んでもよい。そのような通信に使用されるコンポーネントは、ネットワークのタイプ、選択された環境、またはその両方に少なくとも部分的に依存することができる。このようなネットワークを介して通信するためのプロトコルは周知であり、本明細書では詳細に説明しない。したがって、サービスコンピューティングデバイス１０２およびクライアントデバイス１０８は、有線または無線接続、およびそれらの組合せを使用して、１つまたは複数のネットワーク１０６を介して通信することができる。さらに、場合によっては、負荷分散コンピューティングデバイス（図１には図示せず）を、サービスコンピューティングデバイス１０２とクライアントコンピューティングデバイス１０８との間に配置してもよい。さらに、いくつかの例ではネットワーク１０５がＬＡＮおよび／またはストレージエリアネットワークであってもよく、サービスコンピューティングデバイス１０２およびストレージ１０４は互いにローカルに配置されてもよい。

各サービスコンピューティングデバイス１０２は、トランザクションクエリエンジン１１２、通知サービス１１４、ファイルシステムデータベース１１６、およびサーバプログラム１１８を含んでもよい。例えば、サーバプログラム１１８は、ストレージ１０４からファイルを供給するため、および／またはストレージ１０４に格納するためにクライアントデバイス１０８からファイルを受信するためなど、それぞれのクライアントデバイス１０８上のそれぞれのクライアントアプリケーション１２０と対話してもよい。

クライアントデバイス１０８はそれぞれ、クライアントアプリケーション１２０、データ同期サービス１２２、１つまたは複数のファイルシステム１２４、ローカルストレージ１２６、およびトークン１２８を含んでもよい。各クライアントデバイス１０８はストレージ１０４上に格納するためにユーザデータを送信し、ストレージ１０４からデータを取り出すために、サーバプログラム１１８と通信するなどのために、それぞれのクライアントデバイス１０８上で実行することができるクライアントアプリケーション１２０のそれぞれのインスタンスを含んでもよい。

本明細書の他の場所でさらに説明するように、各クライアントデバイス１０８に関連付けられたそれぞれのトークン１２８は、それぞれ、そのクライアントデバイス１０８の現在の構成に特に適用してもよい。したがって、第１クライアントデバイスに関連付けられたトークン１２８（１）は第２クライアントデバイス１０８（２）に関連付けられたトークン１２８（２）とは異なってもよく、第３クライアントデバイス１０８（３）に関連付けられたトークン１２８（３）は、トークン１２８（１）および１２８（２）と異なってもよい。各トークン１２８はサービスコンピューティングデバイス１０２と各クライアントデバイス１０８との間で（例えば、クライアントデバイス１０８に関連するユーザアカウントに基づいて）定義される、ファイルシステムなどの特定のストレージセットの変更を追跡するためのカーソルとして働くことができる。

ファイルシステム１２４は、特定のクライアントデバイス１０８に対してプライベートであり得るプライベートファイルシステム、および／または複数のクライアントデバイス１０８間で共有され得る共有ファイルシステムを含んでもよい。各ユーザは、それぞれのユーザに関連する複数のクライアントデバイスにわたって使用され得るプライベートファイルシステムを有していてもよい。プライベートファイルシステムは、典型的にはそれぞれのユーザによってのみアクセスされてもよい。さらに、一部のユーザは、１つまたは複数の共有ファイルシステムのメンバであってもよく、それらのファイルシステム内のファイルを、同じ１つまたは複数の共有ファイルシステムのメンバでもある他のユーザと共有してもよい。例えば、ユーザが属する共有ファイルシステムは、ユーザのプライベートファイルシステムの下のマウントポイントにマウントされてもよい。

各クライアントデバイス１０８は、そのそれぞれのトークン１１２を使用して、ファイルシステム１２４内のファイルに対する更新または他の変更など、ファイルシステムイベントの更新を受け取ってもよい。サービスコンピューティングデバイス１０２はファイルシステムデータベース１１６を介してクライアントデバイス１０８のファイルシステム１２４を追跡してもよく、ファイルシステムデータベース１１６は、ファイルシステム１２４および関連付けられたクライアントデバイス１０８に関する情報を維持するための任意のタイプのデータ構造としてもよい。例えば、ファイルシステムデータベース１１６は、特定のユーザ１１０の特定のユーザアカウントおよび関連付けられたログイン証明書を、特定のそれぞれのファイルシステム１２４に関連付けてもよい。サービスコンピューティングデバイス１０２によって受信されたファイルシステム１２４に対する変更は、サーバプログラム１１８および／またはトランザクションクエリエンジン１１２に、クライアントデバイス１０８におけるそれぞれのファイルシステム１２４に対する更新を追跡するために、トランザクションクエリエンジン１１２によって使用されるトランザクションログ１３０を特定のファイルシステムに対する変更により更新させるようにしてもよい。

図１の例では、第１ファイルメタデータ１３６および第１ファイルコンテンツ１３８を含む第１ファイル１３４と、第２ファイルメタデータ１４２および第２ファイルコンテンツ１４４を含む第２ファイル１４０とがあると仮定する。さらに、ファイル１３４、１４０のメタデータ１３６、１４２は説明の便宜上、この例ではそれぞれファイルコンテンツ１３８、１４４と共に格納されているように示されているが、実際にはメタデータ１３６、１４２の少なくともいくつかはファイルが存在するファイルシステム１２４のデータ構造に格納されていてもよく、したがって、ファイルコンテンツとは別の格納場所に格納されてもよい。別の代替として、少なくともいくつかのメタデータは、別個のメタデータデータベース（図１には図示せず）に格納されてもよい。

この例では第１ファイル１３４が第１ユーザ１１０（１）および第２ユーザ１１０（２）によって共有される共有ファイルシステムに含まれる共有ファイルであってもよく、第２ファイルは第１ユーザ１１０（１）と共有されない第２ユーザ１１０（２）のプライベートファイルシステムに含まれるプライベートファイルであってもよい。さらに、各クライアントデバイス１０８は、あるファイルがスタブファイルとして維持され、スタブファイルのメタデータのみがローカルストレージ１２６に格納され、ファイルのファイルコンテンツがネットワークストレージ１０４に格納され、ある他のファイルがファイルメタデータおよびファイルのファイルコンテンツの両方と共にローカルストレージ１２６に格納されるように指定するストレージ管理ポリシー（図１には図示せず）を有してもよい。例えば、ユーザが頻繁にアクセスする可能性が高いファイルはローカルストレージ１２６に格納されてもよく、一方、ユーザがまれにしかアクセスしない可能性が高いファイルはファイルのメタデータのみがローカルに格納されるようにスタブされてもよい。

場合によっては、スタブデータ構造が各スタブファイルの他のメタデータに加えて、ローカルストレージ１２６に格納されてもよい。図２に関して以下でさらに説明するように、スタブデータ構造は、最新のファイルコンテンツのハッシュ、ファイルのコンテンツがローカルストレージに存在するかどうかの示唆、およびソフトウェアバージョン情報など、特定のファイルに関連する追加のメタデータを含んでもよい。この例では、第１ファイル１３４が第１および第３クライアントデバイス１０８（１）および１０８（３）上のスタブファイルとして維持され、第１ファイルは第２クライアントデバイス１０８（２）上のファイルコンテンツとともに完全に維持される。したがって、第１ファイル１３４のいくつかのメタデータを含むスタブデータ構造１４６は第１クライアントデバイス１０８（１）および第３クライアントデバイス１０８（３）のローカルストレージ１２６に格納されている一方、第１ファイル１３４のコンテンツ１３８は第２クライアントデバイス１０８（２）のローカルストレージ１２６に格納されている。

同様に、第２ファイル１４０は、第３クライアントデバイス１０８（３）上のスタブファイルとして維持されている。したがって、第２ファイル１４０のいくつかのメタデータを含むスタブデータ構造１４７は第３クライアントデバイス１０８（３）のローカルストレージ１２６に格納されている、一方、第２ファイル１４０のコンテンツ１４４はサービスコンピューティングデバイス１０２によって管理されるネットワークストレージ１０４に格納されている。

どのファイルをスタブファイルとして維持するか、およびどのファイルがファイルコンテンツをローカルに格納するかを決定するためのストレージ管理ポリシーは、ファイルシステム内の特定のフォルダまたはディレクトリに格納されているファイルに基づいて、管理者によってまたはデフォルトによって選択されているファイルまたはフォルダまたはディレクトリに基づいて、最近アクセスされたファイルに基づいて、ユーザによって選択されているファイルに基づいて、および／または様々な他の技法に基づいて決定されてもよい。場合によっては、制限された記憶容量を有するもの（例えば、ポータブルデバイス）などのいくつかのクライアントデバイス１０８について、ストレージ管理ポリシーは、指定されたファイルグループ、ファイルのタイプ、最近アクセスされたファイルなどを除いて、すべてのユーザファイルがスタブファイルとして格納されるように、デフォルト設定を有するようにしてもよい。さらに、場合によっては、大容量のワークステーションまたはデスクトップなどの他のタイプのクライアントデバイス１０８では、指定されたファイルサイズを超え、まれにしかアクセスされないファイルなど、特定のファイルだけをスタブファイルとして格納されるようにしてもよい。例えば、指定されたファイルサイズを超えるファイルが指定された期間アクセスされなかった後、ファイルのコンテンツはローカルストレージ１２６から削除され、ネットワークストレージ１０４でのみ維持されてもよく、一方、ファイルのメタデータはクライアントデバイス１０８のローカルストレージ１２６に維持され、且つ、本明細書の技術を使用して最新の状態に維持されてもよい。

場合によっては、クライアントアプリケーション１２０が、特定のファイル、特定のフォルダ、特定のディレクトリなどをユーザ指定することを可能にするために、ユーザインターフェースを提示するように構成されてもよく、これらは指定された期間の経過後にスタブされる、スタブされない、スタブされるなどである。例えば、デフォルトストレージ管理ポリシーは、ほとんどまたはすべてのファイルがスタブファイルとしてもよく、ユーザまたはシステム管理者が、スタブファイルではない特定のファイル、フォルダなどを指定してもよい。

データ同期サービス１２２はクライアントデバイス１０８上に構成されたファイルシステムに影響を及ぼすイベントの通知を受信するために、通知サービス１１４に登録するために各クライアントデバイス１０８上で実行されてもよい。クライアントデバイス１０８は、特定のクライアントデバイス１０８が登録したファイルシステム１２４に変更があった場合、通知サービス１１４によって通知されてもよい。いくつかの例では、ＨＴＴＰ(ハイパーテキスト転送プロトコル）サーバプッシュ技法またはＨＴＴＰロングポーリング技法を、クライアントデバイス１０８にそれぞれのファイルシステム１２４に対する変更を通知するために使用してもよい。

例えば、ＨＴＴＰロングポーリングの場合、クライアントデバイス１０８は、サービスコンピューティングデバイス１０２が直ちに応答しない可能性があることを予想して、ＨＴＴＰ/Ｓ(セキュアＨＴＴＰ）要求をサービスコンピューティングデバイス１０２に定期的に送信してもよい。特に、サービスコンピューティングデバイス１０２が要求が受信されたときにクライアントデバイス１０８のための新しい情報を有さない場合、空の応答を送信するのではなく、サービスコンピューティングデバイス１０２は、要求を開いたままにして、要求の対象であるファイルシステム１２４のいずれかへの変更を待つようにしてもよい。サービスコンピューティングデバイス１０２が対応するファイルシステムに対する変更の指示を受信した後、通知サービス１１４は直ちに、そのファイルシステムに対して登録されたクライアントデバイス１０８にＨＴＴＰ／Ｓ応答を送信し、オープンＨＴＴＰ／Ｓ要求を完了してもよい。通知サービス１１４からＨＴＴＰ／Ｓ応答を受信すると、クライアントデバイス１０８は任意の追加のファイルシステム変更の任意の後続のプッシュ通知を受信するように、サービスコンピューティングデバイス１０２に別のＨＴＴＰ／Ｓ要求を発行するように構成されてもよい。さらに、クライアントデバイス１０８は更新の詳細を受信するために、以下でさらに説明するように、トランザクションクエリエンジン１１２に要求を発行してもよい。

さらに、または代替として、クライアントデバイス１０８から通知サービス１１４への要求は、クライアントに対して登録された特定のファイルシステムの変更を追跡するためのカーソルとして働くトークンを含んでもよい。トークンは、クライアントがトランザクションクエリエンジン１１２から更新情報を受信したファイルシステムおよび最新のファイルシステムトランザクションを識別してもよい。いくつかの例では、トークンはトランザクションクエリエンジン１１２によってクライアントデバイス１０８に以前に提供されたトークン１２８と同じであってもよく、他の例ではトークンが単に、ファイルシステム識別子と、クライアントデバイスによって受信された最後のトランザクション番号とを含んでもよい。したがって、各クライアントデバイス１０８は、それぞれのトークンに基づいて、どのファイルシステムトランザクションがクライアントデバイス１０８によって見られ、同化されたかを追跡することができる。通知サービス１１４がクライアントデバイス１０８からトークン１２８を受信すると、通知サービス１１４は、識別されたファイルシステムに対応するトランザクションログ１３０をチェックして、トークン１２８に列挙されたトランザクションよりも最近のトランザクションがトランザクションログ１３０にあるかどうかを判定してもよい。トークン１２８の中よりも最近のトランザクションがトランザクションログにある場合、通知サービス１１４は、ファイルシステムに変更があったことを示す応答をクライアントデバイス１０８に送信してもよい。さらに、通知サービス１１４によって使用されるトークンがトランザクションクエリエンジン１１２によって使用されるトークン１２８と異なる場合、通知サービスはファイルシステムに対する変更に基づいてトークンを更新してもよく、クライアントデバイスが通知サービス１１４にクエリを行う次のときに使用するために、更新されたトークンをクライアントデバイス１０８に送信してもよい。いずれの場合も、トークン交換を使用して、クライアントデバイス１０８は、クライアントデバイスが関心を有するファイルシステムに何らかの変更があったときに通知を受けてもよい。

したがって、上述の技法または他の技法を使用して、特定のファイルシステム内のファイルが作成、変更、または削除されると、通知サービス１１４は、サービスコンピューティングデバイス１０２で特定のファイルシステムへの変更が受信されたことを示すファイルシステム変更通知１４８を１つまたは複数の登録済みクライアントデバイス１０８に送信することができる。上述のように、いくつかの例では、ファイルシステム変更通知１４８が更新された通知トークンを含んでもよい。例えば、通知サービス１１４はファイルシステムデータベース１１６を参照して、どのクライアント１０８がどのファイルシステムに対する変更通知を待っているかを判定してもよく、ファイルシステムに対する変更が受信されたクライアントデバイス１０８のみにファイルシステム変更通知１４８を向けてもよい。さらに、いくつかの例では通知サービス１１４が変更通知１４８において、特定のファイルシステムに変更があったことを示してもよいが、通知を引き起こした実際の変更が何であるかを報告しなくてもよい。

通知サービス１１４がクライアントデバイスのファイルシステムに未処理の変更があることを示すファイルシステム変更通知１４８を送信すると、それに応答して、対象のクライアントデバイス１０８のデータ同期サービス１２２は、特定の変更のリストを要求する要求をトランザクションクエリエンジン１１２に送信するように構成してもよい。トランザクションクエリエンジン１１２はトランザクションログ１３０から、および／またはストレージ１０４から直接、情報を決定してもよく、特定の変更のリストを、更新されたトークン１２８と共に要求側のクライアントデバイス１０８に送信することができる。例えば、トランザクションクエリエンジン１１２はトークン１２８を使用して、以下でさらに説明するように、トークン１２８に含まれるトランザクション識別子に基づいて、対応するファイルシステムのイベントを追跡してもよい。

通知サービス１１４からファイルシステム変更通知を受信すると、クライアントデバイス１０８上のデータ同期サービス１２２は、要求１５０と共にクライアントデバイスの現在のトークン１２８をサービスコンピューティングデバイス１０２に送信してもよい。トランザクションクエリエンジン１１２はトークンと、ファイルシステムに対する変更の要求１５０を受信し、受信したトークンに含まれる情報に基づいて、クライアントデバイスのトークンが最後に更新されてから１つまたは複数の指定されたファイルシステムで発生した変更を返してもよい。これにより、クライアントデバイス１０８は、クライアントデバイスが以前に認識していないイベントのみを処理することができる。データ同期サービス１２２は、クライアントデバイス１０８上のローカル構成に基づいて、トランザクションクエリエンジン１１２によって報告された変更のリストを処理する。この処理は、ミラーリングされたファイル構成のためのファイルコンテンツをダウンロードすること、スタブファイル構成のためのスタブメタデータを作成または更新すること、または特定のファイルがストレージ１０４から除去された場合にデータのローカル表現を完全に除去することを含んでもよい。

ユーザまたはアプリケーションが第１クライアントデバイス１０８（１）上の第１ファイル１３４などのスタブファイルであるファイルのコンテンツにアクセスしようと試みる場合、クライアントアプリケーション１２０は、アクセス要求を傍受し、要求されたファイルのコンテンツ１３８がローカルに維持されていないと判定し、コンテンツ１３８の要求をサービスコンピューティングデバイス１０２に送信するオペレーティングシステムレベルのコンポーネントを含んでもよい。一例として、クライアントデバイス１０８がＷＩＮＤＯＷＳを使用している場合は、クライアントアプリケーション１２０を含むことができるか、または使用することができるか スタブされたファイルに向けられたファイルアクセス要求を傍受するように構成された、ＷＩＮＤＯＷＳファイルシステムフィルタドライバを含む、または採用してもよい。ファイルシステムフィルタドライバは、１つまたは複数のファイルシステムまたはファイルシステムボリュームのファイル操作をフィルタすることができるカーネルモードコンポーネントであってもよい。同様のオペレーティングシステムレベルのファイル操作傍受技法を、異なるオペレーティングシステムを採用しているクライアントデバイス１０８上で使用してもよい。

スタブファイルコンテンツにアクセスする要求が傍受されると、クライアントアプリケーションコンポーネントは、要求をサービスコンピューティングデバイス１０２にリダイレクトしてもよい。サービスコンピューティングデバイス１０２上のサーバプログラム１１８は、ストレージ１０４からファイルコンテンツを取り出し、そのファイルコンテンツを要求側のクライアント１０８に送信してもよい。場合によってはクライアントアプリケーション１２０は、サービスコンピューティングデバイス１０２と通信するためにデータＡＰＩ１５４を採用してもよく、サービスコンピューティングデバイスはデータＡＰＩ１５４に従って応答してもよい。上述のように、いくつかの例では、データＡＰＩ１５４はＲＥＳＴ ＡＰＩであってもよい。ファイルコンテンツがサービスコンピューティングデバイス１０２から受信されると、ファイルシステムフィルタドライバは、あたかもファイルコンテンツがローカルストレージにすでに維持されているのと同様な方法で、クライアントデバイス１０８上の要求アプリケーションおよび／またはユーザに応答してもよい。

図１の例では、第２クライアント１１０（２）が、クライアントアプリケーション１１２、第３クライアントデバイス１０８（３）上のオペレーティングシステム（図１には図示せず）、または第３クライアントデバイス１０８（３）上のアプリケーション（図１には図示せず）を使用して、第１ファイル１３４にアクセスすると仮定する。クライアントアプリケーション１１２は、上述したように、サービスコンピューティングデバイス１０２から第１ファイルのファイルコンテンツ１３８を取得してもよい。さらに、第２ユーザ１１０（２）が第１ファイルに変更を行い、その変更をローカルストレージ１２６上のローカル第１ファイルに保存し、第１ファイル１３４を閉じると仮定する。第１ファイル１３４への変更は、第３クライアントデバイス１０８（３）上のデータ同期サービス１２２によってサービスコンピューティングデバイス１０２に同期させてもよい。例えば、更新されたファイルコンテンツおよびメタデータはサーバプログラム１１８に送信されてもよく、サーバプログラム１１８は更新されたファイルコンテンツおよびメタデータをストレージ１０４に格納してもよい。さらに、サーバプログラム１１８はトランザクションログ１３０内の共有ファイルシステムのトランザクション識別子をインクリメントし、共有ファイルシステム内のファイルに対する変更の詳細を含めることなどによって、第１ユーザ１１０（１）および第２ユーザ１１０（２）によって共有されている共有ファイルシステムに対する変更を示すトランザクションログ１３０を更新してもよい。

ファイルシステム変更情報の受信に応答して、サービスコンピューティングデバイス１０２上の通知サービス１１４は、第１クライアントデバイス１０８（１）および第２クライアントデバイス１０８（２）が登録されているファイルシステムデータベース１１６から、共有ファイルシステムの変更通知を受信することを決定してもよい。したがって、通知サービス１１４は、ファイルシステム変更通知１４８を第１クライアントデバイス１０８（１）および第２クライアントデバイス１０８（２）のそれぞれに送信してもよい。これに応答して、第１クライアントデバイス１０８（１）および第２クライアントデバイス１０８（２）のそれぞれは、共有ファイルシステムへの変更を求めるそれぞれの要求１５０と共に、その現在のトークン１２８（１）および１２８（２）を送信してもよい。

これに応答して、トランザクションクエリエンジン１１２は、受信したトークン１２８（１）および１２８（２）内のトランザクション識別子をトランザクションログ１３０内の最新のトランザクション識別子と比較し、第１クライアントデバイス１０８（１）および第２クライアントデバイス１０８（２）のそれぞれで、どのトランザクションが更新されるべきかを決定してもよい。この例では、第１のファイル１３４に対する１つの変更のみがあると仮定する。したがって、トランザクションクエリエンジン１１２は第１クライアントデバイス１０８（１）および第２クライアントデバイス１０８（２）のそれぞれに、変更のリスト１５２とともに修正されたトークンを送信することができる。

したがって、第１ファイル１３４のスタブファイルのみが第１クライアントデバイス１０８（１）のローカルストレージ１２６上に維持されるので、第１クライアントデバイス１０８（１）上のデータ同期サービス１２２は、メタデータ同期１５６のみを実行すればよい。さらに、ファイルコンテンツ１３８が第２クライアントデバイス１０８（２）上のローカルストレージ１２６に格納されるので、第２クライアントデバイス１０８（２）上のデータ同期サービス１２２は、メタデータ同期１５６とコンテンツデータ同期１５８との両方を実行すればよい。

したがって、本明細書の実施形態では、クライアントデバイス１０８は、特定のクライアントデバイス１０８に関連するユーザアカウントおよびログイン証明書に基づいて、特定のファイルシステムへのアクセスが割り当てられる。例えば、各ユーザアカウントは少なくとも１つのプライベートファイルシステム（例えば、特定のユーザアカウントに関連付けられたデバイスのみがファイルシステムを読み取る／書き込むことを許可される）または共有（例えば、複数のユーザアカウントに関連付けされた複数のデバイスがファイルシステムを読み取る／書き込むことを許可される）と対応付けられてもよい。この情報はファイルシステムデータベース１１６内で維持し、追跡してもよい。

場合によっては、サービスコンピューティングデバイス１０２がサービスコンピューティングデバイス１０２に登録されたそれぞれのファイルシステムごとにそれぞれのトランザクションログ１３０を格納することができる。ファイルシステムの各ファイルシステム変更イベント（作成、削除、修正）はそのファイルシステムのトランザクションログ１３０内に対応するエントリを有することができ、それに関連する対応するトランザクション識別子を有することができる。例えば、トランザクション識別子は、トランザクションログ１３０が更新されると、サーバプログラム１１８および／またはトランザクションクエリエンジン１１２によって生成されてもよい。

さらに、上述のように、各クライアントデバイス１０８は、どのファイルがスタブファイルであるか、どのファイルがサービスコンピューティングデバイス１０２からミラーリングされているか等を示す、関連付けられたストレージ管理ポリシー（図１には図示せず）を有してもよい。ストレージ管理ポリシーに基づいて、クライアントデバイスは、ローカルストレージ１２６上のストレージ要件がストレージ空間を節約するために最小限に抑えられるように、データ同期サービス１２２がローカルファイルをスタブするように構成してもよい。例えば、本明細書のスタブデータ管理技法はすべてのデータが常にローカルストレージ内に常駐することを可能にすることなく、ユーザが幅広いデータアレイにアクセスすることを可能にするために、制限されたストレージ容量を有するクライアントデバイス１０８上で使用してもよい。データ同期サービス１２２がストレージ管理ポリシーに基づいてファイルまたは他のデータをスタブすることを決定すると、データ同期サービス１２２は、まず、サービスコンピューティングデバイス１０２がローカルストレージ１２６から削除されるべきファイルコンテンツの最新のフルコピーを受信したことを保証してもよい。次いで、データ同期サービス１２２は除去されたコンテンツデータを表すために、ローカルファイルシステム内にスタブファイルデータ構造を含むスタブファイルを作成することができる。

さらに、クライアントデバイス１０８は各ファイルについて、そのファイルシステム内にメタデータ値のセット（例えば、ファイルコンテンツのファイルサイズ、ファイルコンテンツが最後に変更された時間、ファイルコンテンツのファイルパスなど、本明細書の他の箇所で列挙されているもの）を維持することができ、これは、いくつかの例では第１ファイル１３４のメタデータ１３６に対応していてもよい。このメタデータは、スタブデータ構造自体が小さなプレースホルダに過ぎず、ファイルの実際のコンテンツがクライアントデバイス１０８上に存在しない場合であっても、クライアントデバイス１０８上のオペレーティングシステムおよび／またはユーザにファイルデータを表すために使用してもよい。いくつかの例では、メタデータの記憶位置が実装に依存してもよい。例えば、メタデータ値はファイルシステム自体内に格納されてもよく、または他の例では別個のメタデータデータベース内に維持されてもよい。

本明細書の例では、クライアントデバイス１０８（１）および１０８（３）は、スタブデータ構造１４６をその対応するメタデータ１３６のセットに関連付けて、第１ファイル１３４の仮想表現を提示してもよい。ファイルのデータは、ローカルイベントまたはリモートイベント（例えば、サービスコンピューティングデバイス１０２または別のクライアントデバイス）に少なくとも部分的に基づいて、クライアントデバイス１０８によってスタブされ得る。例えば、クライアントデバイス１０８上のデータ同期サービス１２２は、クライアントデバイス１０８に関連付けられたストレージ管理ポリシーに基づいてローカルディスク空間を解放するために、ローカルに格納されたファイルをスタブファイルに変換することを決定してもよい。さらに、別の例として、共有フォルダに参加する場合、クライアントデバイス１０８上のデータ同期サービス１２２はファイルコンテンツがクライアントデバイス１０８上で実行されるユーザまたはプロセスによって明示的に要求されない限り、ファイルコンテンツを転送するための帯域、およびファイルコンテンツを保持するためのローカルディスク空間のコストが発生しないように、他のクライアントデバイスで最初に実行されるファイル作成をスタブファイルとして表すことを決定してもよい。

さらに、第１ユーザおよび第２ユーザの両方が同時に同じファイルを更新している場合、最初に変更を保存するユーザは他のユーザの前に、それぞれのクライアントデバイス１０８によってサービスコンピューティングデバイス１０２にプッシュされた変更を有してもよい。サービスコンピューティングデバイス１０２は、更新されたファイルにバージョン番号を割り当ててもよい。その後、他のユーザが変更を保存する場合、サービスコンピューティングデバイス１０２は、関連するファイルバージョン番号に基づいて、ファイルが以前のバージョンから既に更新されていることを検出してもよい。この場合、他のユーザはファイルがすでに変更されており、他のユーザによって行われた変更が、更新されたオリジナルのファイルとは別の異なるファイルを使用して保存されていることが通知されてもよい。次いで、他のユーザは、既に更新されたバージョンなどに変更をマージするか、さもなければ組み込むかを決定することによって、競合を解決してもよい。

図２は、いくつかの実施形態によるスタブデータ構造２００の例を示す。例えば、スタブデータ構造２００は、上述の第１のファイル１３４のスタブデータ構造１４６、または本明細書で説明する他のスタブデータ構造に対応してもよい。場合によってはスタブデータ構造２００がファイルコンテンツの代わりにクライアントデバイスのローカルストレージ内のファイルシステムに格納されたスタブファイルメタデータの実際のデータオブジェクトであるが、各スタブファイルの他のメタデータはファイルが格納されているファイルシステムによって、または別個のメタデータデータベース内に維持してもよい。例えば、ファイルサイズ、ファイル修正時間、ファイルパス、ファイルバージョンなどのファイルメタデータのメタデータ値は任意の他の非スタブファイルの場合と同様に、ファイルシステムによって維持してもよい。

この例では、スタブデータ構造２００がソフトウェアバージョン０２０２、コンテンツデータ状態インジケータ２０４、およびファイルコンテンツハッシュ２０６を含む。ソフトウェアバージョンインジケータ２０２はスタブデータ構造２００を生成するために使用されたソフトウェアのバージョン（例えば、クライアントアプリケーションおよび／またはデータ同期サービスのバージョン）を示してもよく、この情報は、スタブデータ構造２００と将来のソフトウェアバージョンとの互換性を維持するために使用してもよい。さらに、コンテンツデータ状態インジケータ２０４は、スタブに対応するファイルのファイルコンテンツがローカルストレージに現在位置しているか、ネットワークストレージ１０４にリモートに現在格納されているかを示してもよい。例えば、コンテンツデータ状態は、１つまたは複数のフラグ、ダーティビットなどによって示されてもよい。さらに、ファイルコンテンツハッシュ２０６は、スタブファイルのファイルコンテンツの最も最近更新されたバージョンのハッシュであってもよい。例えば、ファイルコンテンツハッシュ２０６はファイルコンテンツが検索されるときにスタブデータ構造が正しいファイルコンテンツに関連付けられていることを検証するために使用されてもよく、および／または名前を誤ったスタブなどのために対応するコンテンツを見つけるために使用されてもよい。ＳＨＡ−１、ＳＨＡ−３、ＭＤ−５などの任意の適切なハッシュ関数を使用して、ファイルコンテンツからファイルコンテンツハッシュ２０６を生成してもよい。

図３は、いくつかの実施形態によるトークンデータ構造３００の例を示す。トークンデータ構造３００は、いくつかの実施形態に係るクライアントデバイスにおけるファイルシステム（複数可）に対する更新のリストと共にトランザクションクエリエンジン１１２によって発行されてもよく、上述のトークン１２８に対応してもよい。この例では、トークンデータ構造は、第１ファイルシステム識別子３０２（１）、第２ファイルシステム識別子３０２（２）などの１つまたは複数のファイルシステム識別子３０２を含んでもよい。トークンデータ構造３００に含まれる各ファイルシステム識別子３０２について、トークンデータ構造３００は、関連付けられたマウントポイント情報３０４および関連付けられたトランザクション識別子３０６を含んでもよい。例えば、第１ファイルシステム識別子３０２（１）は、第１マウントポイント情報３０４（１）および第１トランザクション識別子３０６（１）に関連付けられ、第２ファイルシステム識別子３０２（２）は、第２マウントポイント情報３０４（２）および第２トランザクション識別子３０６（２）に関連付けられている。

例えば、ファイルシステム識別子３０２は、対応するクライアントデバイスによって維持されるファイルシステムを示してもよい。マウントポイント情報３０４はファイルシステムに格納されているどの情報（例えば、フォルダ、ファイルなど）が他のクライアントデバイスと共有されている情報であり、どの情報がクライアントデバイスのプライベート情報であるかを示すために使用されてもよい。さらに、トランザクション識別子３０６は、ファイルシステム内の各トランザクションを一意に識別するか、または個別に区別する情報を含むことができるトランザクション識別子情報を含んでもよい。一例として、トランザクション識別子には、トランザクションが上述のトランザクションログに入力される際にトランザクションに順次割り当てられる番号であってもよい。さらに、上述のように、トランザクションクエリエンジン１１２は、クライアントデバイスからの以前に発行されたトークンの受信に応答して、新たに生成されたトークンをクライアントデバイスに送信してもよい。

図４〜１１は、いくつかの実装によるプロセス例を示す流れ図である。プロセスは一連の動作を表す論理流れ図におけるブロックの集合として示されており、これらの動作の一部または全部は、ハードウェア、ソフトウェア、またはこれらの組み合わせで実装してもよい。ソフトウェアの文脈では、１つまたは複数のプロセッサによって実行されると、列挙された動作を実行するようにプロセッサをプログラムする、１つまたは複数のコンピュータ可読媒体上に格納されたコンピュータ実行可能命令を表してもよい。一般に、コンピュータ実行可能命令は、特定の機能を実行するか、または特定のデータタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。ブロックが説明される順序は、限定として解釈されるべきではない。任意の数の説明されたブロックはプロセス、または代替プロセスを実施するために任意の順序で、および／または並列に組み合わせることができ、ブロックのすべてが実行される必要はない。議論の目的のために、プロセスは本明細書の例で説明される環境、フレームワーク、およびシステムを参照して説明されるが、プロセスは多種多様な他の環境、フレームワーク、およびシステムで実装されてもよい。

図４は、いくつかの実施形態による、クライアントデータを更新するための例示的なプロセス４００を示す流れ図である。場合によっては、プロセス４００がクライアントデバイスによって部分的に実行されてもよく、サービスコンピューティングデバイスまたは他の適切なコンピューティングデバイスによって部分的に実行されてもよい。

４０２において、クライアントデバイスは、サービスコンピューティングデバイス上の通知サービスに少なくとも１つのファイルシステムを登録してもよい。例えば、クライアントデバイスは、ユーザログイン証明書などを介して、クライアントデバイスに関連付けられたユーザアカウントに関連付けられたプライベートファイルシステムを登録してもよい。さらに、いくつかの例では、１つまたは複数の共有ファイルシステムを、ユーザアカウントおよびユーザのプライベートファイルシステムに関連付けてもよい。

４０４において、クライアントデバイスは定期的に、サービスコンピューティングデバイス上の通知サービスに、ファイルシステムに対する更新の要求を送信してもよい。いくつかの例では、更新要求を送信するときに、クライアントデバイスは、ＨＴＴＰロングポーリングまたは他の適切な技法を使用してもよい。さらに、場合によってはクライアントデバイスは、更新要求を伴うトークンを含んでもよく、トークンは、少なくとも、クライアントデータが更新された最新のファイルシステムトランザクションのファイルシステム識別子およびトランザクション識別子を含んでもよい。

４０６において、サービスコンピューティングデバイス上の通知サービスはクライアントデバイスから要求を受信してもよく、識別されたファイルシステムに対する変更をチェックしてもよい。例えば、通知サービスは、識別されたファイルシステムのトランザクションログを参照して、トークン内のトランザクション識別子がトランザクションログ内の最新のトランザクション識別子と同じであるかどうかを判定してもよい。

４０８で、トランザクション識別子が同じである場合、保留中の変更はなく、通知サービスは更新がないことを示す応答を送信してもよく、プロセスは、ブロック４０４に戻ってもよい。さらに、場合によっては応答がトークンを含んでもよく、トークンはクライアントデバイスから受信されたトークンと同じであってもよい。一方、トランザクション識別子が同じでない場合、保留中の変更があり、通知サービスはファイルシステム変更があることを示す応答を送信してもよく、プロセスは、ブロック４１０に進んでもよい。いくつかの例では、応答がトランザクションログから取得された更新されたトランザクション識別子を有する更新された通知トークンを含んでもよい。

４１０において、ファイルシステムに変更があるという指示の受信に応答して、クライアントデバイスは、ファイルシステムの変更を求める要求をトランザクションクエリエンジンに送信してもよい。要求は、ファイルシステムデータが最後に更新されたときにトランザクションクエリエンジンから以前に受信されたトークンを含んでもよい。例えば、トークンは図３を参照して上述したように、ファイルシステム識別子、マウントポイント情報、及びトランザクション識別子を含んでもよい。クライアントデバイスがトランザクションクエリエンジンに照会するプロセスの詳細については、図５を参照してさらに説明する。

４１２で、クライアントデバイスはトランザクションクエリエンジンから応答を受信し、処理すべき変更がさらにあるかどうかを判定してもよい。例えば、クライアントデバイスは、まだ処理されていない、トランザクションクエリエンジンから受信した応答にリストされた変更があるかどうかを判定してもよい。処理に変更がなければ、処理はブロック４０４に進む。一方、プロセスに対する変更がさらにある場合、プロセスはブロック４１４に進む。

４１４で、クライアントデバイスは、ファイルシステムに対する変更が作成イベントであるか更新イベントであるかを判定してもよい。変更が作成または更新イベントでない場合、その変更が削除イベントであることを示し、プロセスはブロック４１６に進む。一方、変更が作成イベントまたは更新イベントである場合、プロセスはブロック４１８に進む。

４１６で、変更が削除イベントであると判定することに基づいて、プロセスは、データのローカル表現を削除してもよい。例えば、ファイルの場合、クライアントデバイスは、ローカルファイルシステムから対応するファイルを削除してもよい。次いで、プロセスはブロック４１２に戻り、トランザクションクエリエンジンによって提供された変更のリスト内に、実行するためのさらなる変更が存在するかどうかを判定してもよい。

４１８で、変更が作成イベントまたは更新イベントである場合、クライアントデバイスは、スタビングポリシーがデータに適用されるかどうかを判定してもよい。例えば、クライアントデバイスは、ファイルがクライアントデバイスにおいてスタブファイルとして維持されるか、またはローカルに格納されたファイルコンテンツを含む完全なファイルとして維持されるかを決定してもよい。クライアントデバイスは、スタビングが特定のデータに適用されるかどうかに関する決定を行うときに、クライアントデバイスのために確立されたストレージ管理ポリシーを参照してもよい。スタビングがデータに適用される場合、プロセスはブロック４２２に進む。一方、スタビングがデータに適用されない場合、プロセスはブロック４２０に進む。

４２０で、データがクライアントデバイスでスタブされていない場合、クライアントデバイスは、ファイルの更新されたファイルコンテンツをダウンロードする要求をサービスコンピューティングデバイスに送信してもよい。例えば、クライアントデバイスは対応するファイルの更新されたファイルコンテンツを要求するために、サービスコンピューティングデバイス上のサーバプログラムに要求を送信してもよい。ファイルのメタデータは、クライアントデバイスによってローカルにダウンロードおよび／または作成／更新してもよい。

４２２において、データがクライアントデバイスにおいてスタブファイルとして維持されている場合、クライアントデバイスは、トランザクションクエリエンジンによって提供される情報に基づいてスタブファイルのメタデータを追加および／または更新してもよい。したがって、スタブファイルがクライアントデバイス上にまだ存在しない場合、クライアントデバイスはスタブファイルのスタブデータ構造を追加し、スタブファイルのスタブファイルメタデータをファイルシステムまたは他のメタデータ記憶位置（たとえば、別個のメタデータデータベース）に追加してもよい。あるいは、スタブ・ファイルが既に存在する場合、クライアントデバイスはスタブファイルメタデータを更新してもよい。いずれのイベントの場合も、トランザクションクエリエンジンによって提供される変更情報は、ファイルサイズ、ファイルパス、実行されたイベントのタイプ、修正時間、ファイルバージョン、オブジェクトタイプなどのメタデータ値だけでなく、ファイルのコンテンツの最新のハッシュを含んでもよい。上述のように、クライアントデバイスはファイルサイズ、ファイルパス、イベントタイプ、修正時間、およびファイルバージョンなどのメタデータ値を、クライアントデバイス上のファイルシステムデータ構造または別個のメタデータデータベースに格納してもよく、一方、ファイルコンテンツのハッシュはクライアントデバイス上のローカルストレージに格納されたスタブデータ構造に、またはそれに関連付けて格納してもよい。

図５は、いくつかの実施形態に係る、クライアントがファイルシステムに対する変更についてトランザクションクエリエンジンに問い合わせる例示的なプロセス５００を示す流れ図である。場合によっては、プロセス５００は、クライアントデバイスによって部分的に実行されてもよく、サービスコンピューティングデバイスまたは他の適切なコンピューティングデバイスによって部分的に実行されてもよい。

５０２において、クライアントデバイスは、サービスコンピューティングデバイス上の通知サービスから、クライアントデバイスに関連付けられたファイルシステムに変更があるという指示を受信してもよい。例えば、ファイルシステム変更の通知は、クライアントデバイスによってサービスコンピューティングデバイスに送信された要求に応答するなど、上述の技法のいずれかに基づいて、通知サービスから受信いてもよい。代替的に、他の例では、通知サービスを省いてもよく、クライアントデバイスはトランザクションクエリエンジンに更新要求を定期的に送信してもよく、最も最近に受信されたトークンを要求に含めてもよい。

５０４において、クライアントデバイスは、ファイルシステムに対する変更の要求をサービスコンピューティングデバイスに送信してもよい。クライアントデバイスによって送信される要求は、ファイルシステム識別子と、クライアントデバイスデータが最も最近更新されたトランザクションのトランザクション識別子とを有するトークンを含んでもよい。さらに、本明細書のいくつかの例では、トークンは、たとえば、クライアントのデータのうちのどれがプライベートデータであり、どれが共有データであるかを示すマウントポイント情報を含んでもよい。

５０６において、クライアントデバイスからの要求の受信に応答して、サービスコンピューティングデバイス上のトランザクションクエリエンジンは、クライアントデバイスから受信されたトークンに含まれるトランザクション識別子によって指定されたトランザクションの後に発生した、指定されたファイルシステムに対する更新のリストを決定してもよい。

５０８において、サービスコンピューティングデバイス上のトランザクションクエリエンジンは、ファイルシステムに対する変更のリストおよび／または対応するトランザクションＩＤを有する更新されたトークンをクライアントデバイスに送信してもよい。例えば、ファイルシステムに対する全ての変更が既にクライアントデバイスに送信されている場合、トランザクションクエリエンジンは最新のトランザクション識別子を含み、追加の変更のリストを含まないトークンを返すだけでよい。

５１０において、クライアントデバイスは、変更のリストに基づいてクライアントデバイス上のデータを同期させてもよい。同期化の詳細は、図４に関して上述されている。

５１２で、クライアントデバイスは、トランザクションＩＤを追跡して、別の要求を送信するかどうかを決定してもよい。例えば、トランザクションクエリエンジンから受信された最新のトークン内のトランザクション識別子が以前に受信されたトークンのトランザクション識別子と一致し、変更のリストが同じであるか、または変更のリストが含まれていない場合、クライアントデバイスは最新である。

５１４で、クライアントデバイスは、現在のトークン内のトランザクションＩＤを直前に受信したトークン内のトランザクションＩＤと比較することに基づいて、トランザクションクエリエンジンに別の要求を送信するかどうかを決定してもよい。トランザクションＩＤが同じである場合、プロセスはブロック５１６に進んでもよい。一方、トランザクションＩＤが異なる場合、プロセスはブロック５０４に進み、別の要求をトランザクションクエリエンジンに送信してもよい。

５１６で、クライアントデバイスデータは最新であり、プロセスは図４のブロック４０４に戻り、ファイルシステムへの追加の変更を待つてもよい。上述したように、トランザクションクエリエンジンから新しいトークンとともに変更のバッチを送信し、クライアントデバイスによって新しいトークンをトランザクションクエリエンジンに戻し、トランザクションクエリエンジンから、次の新しいトークンと増分されたトランザクション識別子とともに、変更の次のバッチを受信する処理は、それ以上更新がなくなるまで繰り返してもよい。その時点で、トランザクションクエリエンジンは最新のトランザクションのトランザクションＩＤを有するトークンを送信してもよく、クライアントデバイスは、次のファイルシステム変更通知が通知サービスから受信されるまで、このトークンを保持してもよい。トランザクションクエリエンジン、トークン、およびクライアントデバイスの更新に関する追加の情報は２０１３年１２月１７日に出願された国際出願ＰＣＴ／ＵＳ２０１３／０７５８５５、および２０１６年２月２９日に出願されたその米国国内段階出願第１４／９１５，４２３号に含まれており、それらの全体が参照により本明細書に組み込まれる。

図６は、いくつかの実施形態に係る、スタブファイルまたは他のスタブデータオブジェクトのメタデータを作成および／または更新するための例示的なプロセス６００を示す流れ図である。場合によっては、プロセス６００は、クライアントデバイスまたは他の適切なコンピューティングデバイスによって実行されてもよい。

６０２において、図４のブロック４１８および４２２に関して上述したように、クライアントデバイスは、クライアントデバイスのデータ記憶ポリシーがデータオブジェクトがスタブファイルとして維持されるべきであること、およびスタブファイルのメタデータ情報がファイルシステムに対する変更に基づいて作成または更新されるべきであることを示すことを決定してもよい。一例として、データオブジェクトは、別のクライアントデバイス上で更新されたファイルであってもよい。

６０４において、クライアントデバイスは、ローカルスタブファイルがデータについて既に存在するかどうかを判定してもよい。そうであれば、プロセスはブロック６０８に進み、そうでなければ、プロセスはブロック６０６に進む。

６０６で、クライアントデバイスはデータのためのスタブデータ構造を作成し、データのためのスタブメタデータを作成してもよい。例えば、データオブジェクトが、新たに作成されたファイルなどのファイルシステムに新たに追加される場合、クライアントデバイスは新たなスタブファイルのための新たなスタブデータ構造を作成し、トランザクションクエリエンジンによって提供される情報から新たなスタブファイルのための新たなスタブファイルメタデータを決定してもよい。したがって、トランザクションクエリエンジンから受信された情報は、ファイルコンテンツのハッシュと、ファイル作成時間、ファイルサイズ、および／または他のファイルプロパティなど、新しく作成されたスタブファイルの他のメタデータ値とを含んでもよい。ファイルコンテンツのハッシュはスタブデータ構造に格納してもよく、一方、他のファイルメタデータはクライアントデバイス上のファイルシステムに、またはクライアントデバイス上のローカルストレージに維持される別個のメタデータデータベースに格納してもよい。

一方、６０８において、データオブジェクトがファイルシステム内に既に存在する場合、クライアントデバイスは、サービスコンピューティングデバイスとまだ同期されていないデータオブジェクトのローカルに格納されたデータがあるかどうかを判定してもよい。例えば、クライアントデバイスのユーザがデータオブジェクトに何らかの変更を行った場合、データオブジェクトがスタブ表現に変更される前に、変更がサービスコンピューティングデバイスと同期されない場合、これらの変更は失われる可能性がある。一例として、クライアントデバイス上のデータ同期サービスは、クライアントデバイスによって維持されるファイル同期情報を参照して、まだ同期されていないファイルコンテンツまたは他のデータコンテンツに対して何らかのデータ変更が行われたかどうかを判定してもよい。例えば、データ同期サービスは、どのデータがクライアントデバイスからサービスコンピューティングデバイスに同期されたかを示すファイル同期情報のデータベースまたは他のデータ構造を維持してもよい。ローカルデータがない場合、または、いずれかのローカルデータが既にサービスコンピューティングデバイスに同期されている場合、プロセスはブロック６１０に進む。一方、ローカルデータが存在し、サービスコンピューティングデバイスにまだ同期されていない場合、プロセスはブロック６１２に進む。

６１０において、ローカルデータが存在しないか、または任意のローカルデータがサービスコンピューティングデバイスにすでに同期されている場合、クライアントデバイスは、ファイルシステム内およびスタブファイルのスタブデータ構造内のスタブファイルメタデータを更新してもよい。データオブジェクトが完全に維持されたファイルからスタブファイルに変換されている場合、スタブデータ構造を作成してもよい。上述のように、クライアントデバイスはトランザクションクエリエンジンから受信した情報からコンテンツのハッシュおよび他の更新されたメタデータを決定してもよく、または最新のコンテンツがクライアントデバイス上に存在する場合、クライアントデバイスは、コンテンツを削除する前にコンテンツからハッシュを計算してもよい。

６１２において、サービスコンピューティングデバイスに同期されていないローカルデータがある場合、クライアントデバイスはスタブ処理を中止し、同期のためにローカル変更をサービスコンピューティングデバイスに送信してもよい。一例として、クライアントデバイスは図４および図５に関して上述したように、ファイルシステムに対する変更の次の更新中に、データオブジェクトのスタブ処理を再開してもよい。

図７は、いくつかの実施形態に係る、ファイルのためのスタブファイルを作成するための例示的なプロセス７００を示す流れ図である。この例では、ファイルが例えば、クライアントデバイス上のプライベートファイルシステム内で作成され、サービスコンピューティングデバイスに同期されてもよい。上述のように、プライベートファイルシステムは、ユーザアカウントまたはユーザ識別子およびユーザログイン証明書に基づいて、クライアントデバイスに関連付けることができる。一例として、クライアントデバイスは、クライアントデバイスのストレージ管理ポリシーに基づいて、ローカルファイルをスタブファイルに変換することを決定してもよい。

７０２において、クライアントデバイスは、クライアントデバイスにおいて第１ファイルを作成してもよい。例えば、ユーザは、アプリケーションまたは他のプロセスを使用して、クライアントデバイスでファイルを作成してもよい。

７０４において、クライアントデバイスは第１ファイルがスタブファイルとして維持されるべきか、または完全に維持されたファイルとして維持されるべきかを決定するために、ストレージ管理ポリシーをチェックしてもよい。例えば、ストレージ管理ポリシーは、ファイルタイプ、ストレージ使用限度、ファイルストレージ位置、デフォルトポリシー、または上述の様々な他の考慮事項のいずれかに基づいて、どのファイルがスタブファイルであるかを示すようにしてもよい。

７０６で、クライアントデバイスは、ストレージ管理ポリシーの１つまたは複数の基準に基づいて、第１ファイルをスタブファイル候補として選択してもよい。

７０８において、クライアントデバイスは、第１のファイルのファイルコンテンツをサービスコンピューティングデバイスに同期させてもよい。例えば、クライアントデバイス上のデータ同期サービスはどのファイルがサービスコンピューティングデバイスに完全に同期されているか、およびどのファイルが同期されていないかを追跡するために、ファイル同期情報を維持してもよい。したがって、ファイル同期情報に基づいて、データ同期サービスはファイルをスタブファイルに変換する前に、最新のファイルコンテンツがサービスコンピューティングデバイスに同期されていることを保証することができ、その結果、ファイルコンテンツがファイルシステムから削除されたときに、ファイルコンテンツに対する任意の変更が失われない。

７１０で、クライアントデバイスは第１ファイルのメタデータを記録し、削除のために第１ファイルコンテンツにマークを付け、スタブデータ構造を作成してもよい。例えば、スタブデータ構造を作成するとき、クライアントデバイスは第１ファイルコンテンツを削除する前に第１ファイルコンテンツのハッシュを計算してもよく、ファイルサイズ、修正時間、パス、バージョン番号などの他のスタブファイルメタデータ値を決定してもよい。

７１２で、クライアントデバイスは、スタブファイルメタデータを使用して、第１ファイルのローカルオペレーティングシステムビューを提示して、第１ファイルの実際のファイルコンテンツの最新の表現を反映してもよい。例えば、ユーザがオペレーティングシステムウィンドウを開いてファイルシステム構造を見る場合、第１ファイルは第１ファイルがクライアントデバイス上に完全に維持されているのと同様な方法により、ファイルシステム構造内に表してもよい。

７１４で、クライアントデバイスは、第１ファイルのファイルコンテンツにアクセスするためのユーザ要求またはアプリケーション要求を受信してもよい。例えば、要求は、オペレーティングシステムを介して、またはクライアントデバイス上で実行されるアプリケーションを介して受信してもよい。

７１６において、クライアントデバイス上のクライアントアプリケーションは要求を傍受し、サービスコンピューティングデバイスからファイルコンテンツを取得してもよい。一例として、クライアントアプリケーションに関連するファイルシステムフィルタドライバまたは他のオペレーティングシステムレベルコンポーネントは、スタブファイルであるファイルに向けられたファイルアクセス要求を傍受するように構成してもよい。スタブファイルのコンテンツにアクセスする要求が傍受されると、クライアントアプリケーションコンポーネントは、要求をサービスコンピューティングデバイスにリダイレクトしてもよい。サービスコンピューティングデバイス上のサーバプログラムはネットワークストレージからファイルコンテンツを取り出し、そのファイルコンテンツを要求側クライアントデバイスに送信してもよい。場合によっては、クライアントアプリケーションがＲＥＳＴ ＡＰＩなどのデータＡＰＩを使用して、サービスコンピューティングデバイスと通信してもよい。

７１８で、クライアントデバイスは、要求に応答してファイルコンテンツを提供してもよい。例えば、ファイルコンテンツがサービスコンピューティングデバイスから受信された場合、ファイルシステムフィルタドライバは、あたかもファイルコンテンツがクライアントデバイス上のローカルストレージに既に格納されているのと同様な方法により、クライアントデバイス上の要求アプリケーションおよび／またはユーザに応答してもよい。

図８は、いくつかの実施形態による、リモート更新に基づいてスタブファイル情報を更新するための例示的なプロセス８００を示す流れ図である。場合によっては、プロセス８００は、複数のクライアントデバイスにわたって共有ファイルシステムまたはプライベートファイルシステムが実装されている場合など、複数のクライアントデバイスが同じファイルにアクセスすることができる環境で実行してもよい。

８０２において、第１クライアントデバイスは、第１クライアントデバイスにおいて第１ファイルのためのスタブファイルを作成してもよく、第１ファイルの第１ファイルコンテンツは、その後、第２クライアントデバイスによってアクセスされてもよい。例えば、上述のように、第１クライアントデバイスはスタブデータ構造を生成し、第１ファイルのための他のスタブメタデータを取得または生成し、第１のクライアントデバイスから第１ファイルのファイルコンテンツを削除することによって、第１ファイルのためのスタブファイルを作成してもよい。

８０４において、第２クライアントデバイスは、第１ファイルを修正してもよい。例えば、第２クライアントデバイスは、第１ファイルのスタブファイルが第１クライアントデバイス上で作成されたか、または最後に更新されたときに、ファイルコンテンツの状態と比較して、第１ファイルのファイルコンテンツを変更してもよい。

８０６において、第２クライアントデバイスは、第２クライアントデバイスからサービスコンピューティングデバイスに、第１ファイルの修正を送信してもよい。例えば、第２クライアントデバイスはネットワークストレージに記憶するために、サービスコンピューティングデバイスに対して修正を同期させてもよい。

８０８において、サービスコンピューティングデバイス上の通知サービスは、第１ファイルが格納されているファイルシステムにファイルシステム変更を通知するクライアントデバイスを決定してもよい。例えば、通知サービスは、様々な異なるクライアントデバイスと様々な異なるファイルシステムとの間の関連付けをリストする、サービスコンピューティングデバイスに維持されるファイルシステムデータベースにアクセスしてもよい。

８１０において、第１クライアントデバイスは、第１ファイルを含むファイルシステムに対する変更があることを示すファイルシステム変更通知を通知サービスから受信してもよい。あるいは他の例では通知サービスを省いてもよく、クライアントデバイスはトランザクションクエリエンジンに変更要求を定期的に送信してもよい。

８１２で、通知の受信に応答して、第１クライアントデバイスは、ファイルシステム変更に関する情報の要求およびトークンをトランザクションクエリエンジンに送信してもよい。プロセスのさらなる詳細は例えば、図４および図５に関して上述されている。

８１４で、第１クライアントデバイスは、トランザクションクエリエンジンからの変更情報および新しいトークンを受信してもよい。例えば、変更情報は、第１ファイルのパス、操作種別、ファイルサイズ、ファイル修正時間などを含んでもよい。新しいトークンは、ファイルシステムのためのより最近のトランザクション識別子を含んでもよい。

８１６で、第１クライアントデバイスは、ファイルシステム変更情報を処理し、ローカルな第１ファイルの状態をチェックし、変更情報に基づいてスタブファイルメタデータを更新してもよい。例えば、スタブファイルメタデータを更新するとき、第１クライアントは、トランザクションクエリエンジンによって提供された情報から更新されたファイルコンテンツのハッシュを決定し、受信したハッシュをスタブデータ構造に格納してもよい。したがって、第１クライアントは、更新されたファイルコンテンツをダウンロードする必要なしに、パス、イベントのタイプ、修正時間、ファイルの新しいサイズ、実際の更新されたファイルコンテンツのハッシュ、ファイルのバージョン番号などを含むスタブファイルのメタデータを更新してもよい。

８１８において、第１クライアントデバイスは、第１ファイルに関連するユーザ要求を受信してもよい。例えば、ユーザは、ウィンドウを開いて、第１ファイルを含むファイルシステムを見てもよい。

８２０で、第１クライアントデバイス上のローカルオペレーティングシステムは、第１ファイルの更新されたスタブメタデータに基づいて、最新の表現を有する第１ファイルのビューを提示してもよい。

図９は、いくつかの実施形態に係る、リモートで作成されたファイルをスタブするための例示的なプロセス９００を示す流れ図である。場合によっては、プロセス９００は、複数のクライアントデバイス上で実施される共有ファイルシステムまたはプライベートファイルシステムの場合など、複数のクライアントデバイスが同じファイルにアクセスすることができる環境で実行してもよい。したがって、いくつかの例では、プロセス９００は、第１クライアントデバイスおよび第２クライアントデバイスによって実行されてもよい。

９０２において、第２クライアントデバイスは、第２クライアントデバイスにおいて第１ファイルを生成してもよい。この例では、第１クライアントデバイスは、現在、第１ファイルのローカル表現を有していない。

９０４において、第２クライアントデバイスは、同期のために、第１ファイルメタデータおよび第１ファイルコンテンツをサービスコンピューティングデバイスに送信してもよい。

９０６において、第１クライアントデバイスは、サービスコンピューティングデバイス上の通知サービスからファイルシステム変更通知を受信してもよい。

９０８で、第１クライアントデバイスは、ファイルシステム変更に関する情報及びトークンの要求をトランザクションクエリエンジンに送信してもよい。

９１０で、第１クライアントデバイスは、トランザクションクエリエンジンからのファイルシステム変更情報のリストおよび新しいトークンを受信してもよい。

９１２において、第１クライアントデバイスはファイルシステム変更情報を処理し、ローカルな第１ファイルの状態をチェックし、第１ファイルのローカル表現が存在しないことを決定してもよい。

９１４において、第１クライアントデバイスは、第１クライアントデバイスのストレージ管理ポリシーに基づいて、第１ファイルがスタブファイルとして維持されるべきであると決定してもよい。

９１６において、第１クライアントデバイスは、スタブデータ構造と、スタブファイルを作成するための他のファイルシステムメタデータとを含む、第１ファイルのスタブファイルメタデータを決定してもよい。例えば、第１クライアントデバイスは、トランザクションクエリエンジンから受信されたファイルシステム変更情報のリストからスタブファイルメタデータ情報を取得してもよく、このスタブファイルメタデータ情報は、ファイルコンテンツのハッシュ、ファイルサイズ、ファイルパス、ファイル修正時間などを含んでもよい。

９１８において、第１クライアントデバイスは、第１ファイルに関連するユーザ要求を受信してもよい。例えば、第１クライアントデバイスのユーザは、ウィンドウを開いて、第１ファイルを含むファイルシステムを見てもよい。

９２０で、第１クライアントデバイス上のローカルオペレーティングシステムは、第１ファイルの更新されたスタブファイルメタデータに基づいて、最新の表現（例えば、ファイルサイズ、最新の修正時間、現在のパスなどの最新のファイルメタデータ値）を有する第１ファイルのビューを提示してもよい。

図１０は、いくつかの実施形態に係る、スタブファイルがリモートで削除される例示的なプロセス１０００を示す流れ図である。場合によっては、プロセス１０００は、複数のクライアントデバイス上で実装される共有ファイルシステムまたはプライベートファイルシステムの場合など、複数のクライアントデバイスが同じファイルにアクセスすることができる環境で実行されてもよい。したがって、いくつかの例では、プロセス１０００は、第１クライアントデバイスおよび第２クライアントデバイスによって実行されてもよい。

１００２で、第１クライアントデバイスは、第１クライアントデバイスのファイルシステム内に第１ファイルのスタブを作成してもよい。

１００４において、第２クライアントデバイスは、ファイルシステムから第１ファイルを削除するユーザ命令を受信してもよい。

１００６で、第２クライアントデバイスはファイルシステムから第１ファイルを削除し、ファイル情報の削除をサービスコンピューティングデバイスに送信してもよく、ファイル情報の削除は、第１ファイルに、ネットワークストレージから削除するためのフラグを立てる。

１００８において、第１クライアントデバイスは、サービスコンピューティングデバイス上の通知サービスからファイルシステム変更通知を受信してもよい。

１０１０で、第１クライアントデバイスはトランザクションクエリエンジンからファイルシステムへの変更に関する情報を要求してもよく、要求とともにトークンを含んでもよい。

１０１２で、第１クライアントデバイスは、トランザクションクエリエンジンからの変更情報および新しいトークンを受信してもよい。この例では、変更情報は、イベントがファイルの削除であることを示してもよい。

１０１４で、第１クライアントデバイスは変更情報を処理し、第１ファイルのローカル表現をファイルシステムから除去してもよい。例えば、第１クライアントデバイスは、第１クライアントデバイス上のファイルシステムからスタブデータ構造および他のスタブファイルメタデータを削除してもよい。

１０１６で、第１クライアントデバイスのユーザがファイルシステムにアクセスすると、ファイルシステムのローカルオペレーティングシステムビューは、第１ファイルが削除されたファイルシステムの最新の表現を反映してもよい。さらに、本明細書のいくつかの例では、スタブファイルへの名前変更が上述したように、ファイル削除操作とファイル作成操作との組合せとして扱われてもよい。

図１１は、いくつかの実施形態に係る、データをミラーリングするための例示的なプロセス１１００を示す流れ図である。プロセス１１００は、クライアントデバイスが、任意の可能なパスのためなどに、ミラーリング処理とスタブ処理との両方を同時に実行することができることを示す。場合によっては、プロセス１１００は、複数のクライアントデバイスにわたって実装される共有ファイルシステムまたはプライベートファイルシステムの場合など、複数のクライアントデバイスが同じファイルにアクセスすることができる環境で実行されてもよい。したがって、いくつかの例では、プロセス１１００は、第１クライアントデバイスおよび第２クライアントデバイスによって実行されてもよい。

１１０２において、第２クライアントデバイスは、第２クライアントデバイスにおいて第１ファイルを生成してもよい。この例では、第１クライアントデバイスは、現在、第１ファイルのローカル表現を有していない。

１１０４において、第２クライアントデバイスは、同期のために、第１ファイルメタデータおよび第１ファイルコンテンツをサービスコンピューティングデバイスに送信してもよい。

１１０６において、第１クライアントデバイスは、サービスコンピューティングデバイス上の通知サービスからファイルシステム変更通知を受信してもよい。

１１０８で、第１クライアントデバイスは、ファイルシステム変更に関する情報の要求およびトークンをトランザクションクエリエンジンに送信してもよい。

１１１０で、第１クライアントデバイスは、トランザクションクエリエンジンからの変更情報のリストおよび新しいトークンを受信してもよい。

１１１２において、第１クライアントデバイスはファイルシステム変更情報を処理し、ローカルな第１ファイルの状態をチェックし、第１ファイルのローカル表現が存在しないと判定してもよい。

１１１４において、第１クライアントデバイスは、第１ファイル内容への更新が第１クライアントデバイスに記憶されるように、第１ファイルが第１クライアントデバイス上のミラー構成に維持されるべきであると、ストレージ管理ポリシーから判断してもよい。

１１１６で、第１クライアントデバイスは、第１ファイルのファイルコンテンツをダウンロードし、トランザクションクエリエンジンから受信した変更情報に含まれるメタデータに追加のメタデータを適用してもよい。例えば、追加のメタデータは、第１クライアントデバイス上で維持される第１ファイルコンテンツのミラーリング関係などに関連していてもよい。

１１１８において、第１クライアントデバイスのユーザが、ファイルシステムにアクセスすると、ファイルシステムのローカルオペレーティングシステムビューは、ファイルシステムにおける最新のミラー状態を有することを示す第１ファイルコンテンツを有するファイルシステムの最新の表現を反映してもよい。

本明細書に記載される例示的なプロセスは、議論の目的のために提供されるプロセスの例に過ぎない。本明細書の開示に照らして、多数の他の変形が当業者には明らかであろう。さらに、本明細書の開示はプロセスを実行するための適切なフレームワーク、アーキテクチャ、および環境のいくつかの例を示しているが、本明細書の実装は、示され且つ論じられた特定の例に限定されない。さらに、本開示は記載され、図面に図示されるように、様々な例示的な実施形態を提供する。しかし、本開示は本明細書に記載され、図示された実施形態に限定されず、当業者に知られているように、または知られるように、他の実施形態に拡張することができる。

図１２は、いくつかの実施形態に係る、サービスコンピューティングデバイス１０２およびストレージ１０４の選択コンポーネントの構成例を示す。いくつかの例では、サービスコンピューティングデバイス１０２は、任意のさまざまな方法で実施することができる１つまたは複数のサーバまたは他のタイプのコンピューティングデバイスを含んでもよい。例えば、サーバの場合、モジュール、他の機能コンポーネント、およびデータストレージの少なくとも一部は、少なくとも１つのサーバ、例えば、サーバファームまたはデータセンター、クラウドホストコンピューティングサービスなどに実装されてもよいが、他のコンピュータ構造を追加または代替として使用してもよい。

図示の例では、各サービスコンピューティングデバイス１０２は、１つまたは複数のプロセッサ１２０２、１つまたは複数のコンピュータ可読媒体１２０４、および１つまたは複数の通信インターフェース１２０６を含むか、またはそれに関連付けてもよい。各プロセッサ１２０２は単一の処理ユニットまたは複数の処理ユニットとしてもよく、単一または複数の計算ユニット、または複数の処理コアを含んでもよい。プロセッサ１２０２は、１つまたは複数の中央処理装置、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、ステートマシーン、論理回路、および／または動作命令に基づいて信号を操作する任意のデバイスとして実装することができる。例えば、プロセッサ１２０２は、本明細書で説明されるアルゴリズムおよびプロセスを実行するように特にプログラムまたは構成された任意の適切なタイプの１つまたは複数のハードウェアプロセッサおよび／または論理回路としてもよい。プロセッサ１２０２は本明細書で説明する機能を実行するようにプロセッサ１２０２をプログラムすることができる、コンピュータ可読媒体１２０４に格納されたコンピュータ可読命令をフェッチし、実行するように構成することができる。

コンピュータ可読媒体１２０４は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなど、デジタル情報を記憶するための任意のタイプの技術で実装された揮発性および不揮発性メモリ、ならびに／またはリムーバブルおよび非リムーバブル媒体を含んでもよい。例えば、コンピュータ可読媒体１２０４はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、光ストレージ、ソリッドステートストレージ、磁気ディスクストレージ、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、または所望の情報を格納するために使用することができ、コンピューティングデバイスによってアクセスすることができる任意の他の媒体を含んでもよいが、これらに限定されない。サービスコンピューティングデバイス１０２の構成に応じて、コンピュータ可読媒体１２０４は、言及された場合、非一時的なコンピュータ可読媒体がエネルギー、搬送波信号、電磁波、および／または信号自体などの媒体を除外する限り、有形の非一時的媒体であってよい。場合によってはコンピュータ可読媒体１２０４は、サービスコンピューティングデバイス１０２と同じ場所にあってもよく、他の例ではコンピュータ可読媒体１２０４がサービスコンピューティングデバイス１０２から部分的に離れていてもよい。例えば、場合によっては、コンピュータ可読媒体１２０４がストレージ１０４内のストレージの一部を含んでもよい。

コンピュータ可読媒体１２０４は、プロセッサ１２０２によって実行可能な任意の数の機能コンポーネントを格納するために使用されてもよい。多くの実施形態ではこれらの機能コンポーネントがプロセッサ１２０２によって実行可能であり、実行されると、具体的にはサービスコンピューティングデバイス１０２に帰属するアクションを実行するようにプロセッサ１２０２をプログラムする命令またはプログラムを含む。コンピュータ可読媒体１２０４に格納された機能コンポーネントは、トランザクションクエリエンジン１１２、通知サービス１１４、およびサーバプログラム１１８を含んでもよく、これらの各々は、１つまたは複数のコンピュータプログラム、アプリケーション、実行可能コード、またはそれらの一部を含んでもよい。例えば、サーバプログラム１１８は、クライアントコンピューティングデバイス１０８およびストレージシステム１０４との通信機能を提供してもよい。コンピュータ可読媒体１２０４に格納された追加の機能コンポーネントは、サービスコンピューティングデバイス１０２の様々な機能を制御および管理するためのオペレーティングシステム１２０８を含んでもよい。場合によっては、機能コンポーネントは、コンピュータ可読媒体１２０４の記憶部分に格納され、コンピュータ可読媒体１２０４のローカルメモリ部分にロードされ、１つまたは複数のプロセッサ１２０２によって実行されてもよい。

さらに、コンピュータ可読媒体１２０４は、本明細書で説明される機能およびサービスを実行するために使用されるデータおよびデータ構造を格納してもよい。例えば、コンピュータ可読媒体１２０４は、トランザクションログ１３０、ファイルシステムデータベース１１６、およびデータＡＰＩ１５４を格納してもよい。サービスコンピューティングデバイス１０２は、プログラム、ドライバなどを含むことができる他のモジュールおよびデータ１２１０、ならびに機能コンポーネントによって使用または生成されるデータなど、他の機能コンポーネントおよびデータを含むか、または維持してもよい。さらに、サービスコンピューティングデバイス１０２は多くの他の論理的、プログラム的、および物理的構成要素を含むことができ、それらの上で説明したものは、本明細書の議論に関連する例にすぎない。

通信インターフェース１２０６は、ネットワーク１０５および１０６を介するなど、様々な他のデバイスとの通信を可能にするための１つまたは複数のインターフェースおよびハードウェア構成要素を含んでもよい。したがって、通信インターフェース１２０６はストレージシステム１０４と通信するためのネットワーク１０５への接続を提供する１つまたは複数のポートと、クライアントコンピューティングデバイス１０８または他のコンピューティングデバイスと通信するためのネットワーク１０６への接続を提供する１つまたは複数のポートとを含んでもよく、またはそれらに結合してもよい。例えば、通信インターフェース１２０６は、本明細書の他の場所にさらに列挙されている通り、ＬＡＮ、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えば、Ｗｉ−Ｆｉ）および有線ネットワーク（例えば、ファイバチャネル、光ファイバ、イーサネット）、直接接続、ならびにＢＬＵＥＴＯＯＴＨ（登録商標）の１または複数を介して通信可能であってもよい。

図１２の例は、いくつかの実施形態に係る１つまたは複数のサービスコンピューティングデバイス１０２の１つの可能な構成例を示す。この例では、第１サービスコンピューティングデバイス１０２（１）は、第２サービスコンピューティングデバイス１０２（２）に接続されてもよい。例えば、第１サービスコンピューティングデバイス１０２（１）および第２サービスコンピューティングデバイス１０２（２）は、複数のクライアントコンピューティングデバイス１０８（図１２には図示せず）に記憶およびデータ管理サービスを提供するためのコンピューティングデバイスを一緒に構成してもよい。いくつかの例では第１サービスコンピューティングデバイス１０２（１）は、少なくともトランザクションログ１３０およびファイルシステムデータベース１１６を維持することに関して、マスタまたは１次コンピューティングデバイスとして働いてもよく、第２サービスコンピューティングデバイス１０２（２）はスレーブまたは２次コンピューティングデバイスとして働いてもよい。例えば、第１サービスコンピューティングデバイス１０２（１）上のサーバプログラム１１８、通知サービス１１４、および／またはトランザクションクエリエンジン１１２は、第１サービスコンピューティングデバイス１０２（１）上のトランザクションログ１３０およびファイルシステムデータベース１１６を更新し、維持してもよい。１２１１に示すように、第１サービスコンピューティングデバイス１０２（１）上のサーバプログラム１１８または他のプログラムは、トランザクションログ１３０およびファイルシステムデータベース１２２を第２サービスコンピューティングデバイス１０２（２）に複製してもよい。したがって、第１サービスコンピューティングデバイス１０２（１）が故障した場合、第２サービスコンピューティングデバイス１０２（２）は、第１サービスコンピューティングデバイス１０２（１）が異なるサービスコンピューティングデバイス（図２には図示せず）に置き換えられ、または修理されるまで、一次コンピューティングデバイスの役割を担ってもよい。この時間の間、第２サービスコンピューティングデバイス１０２（２）は、上述したファイルスタブのためのデータ管理サービスを実行してもよい。

図示の例ではストレージ１０４がストレージシステム１２１２内に維持されるが、本明細書の実施形態は本明細書に示され、かつ／または説明されるストレージ例に限定されない。ストレージシステム１２１２は１つまたは複数のストレージコンピューティングデバイス１２１４を含むことができ、ストレージコンピューティングデバイス１２１４は、サービスコンピューティングデバイス１０２に関して上述した例のいずれかなど、１つまたは複数のサーバまたは任意の他の適切なコンピューティングデバイスを含んでもよい。ストレージコンピューティングデバイス１４０は、それぞれ、１つまたは複数のプロセッサ１２１６、１つまたは複数のコンピュータ可読媒体（ＣＲＭ）１２１８、および１つまたは複数の通信インターフェース（Ｉ／Ｆ）１２２０を含んでもよい。例えば、プロセッサ１２１６はプロセッサ１２０２に関して上述した例のいずれかに対応してもよく、コンピュータ可読媒体１２１８はコンピュータ可読媒体１２０４に関して上述した例のいずれかに対応してもよく、通信インターフェース１２２０は、通信インターフェース１２０６に関して上述した例のいずれかに対応してもよい。

さらに、コンピュータ可読媒体１２１８はストレージシステム１２１２に含まれるストレージ１０４上のデータの記憶を管理するために、１つまたは複数のプロセッサ１２０２によって実行される機能コンポーネントとしてストレージプログラム１２２２を含んでもよい。ストレージ１０４は、ストレージデバイス１２２８の１つまたは複数のアレイ１２２６上にデータを格納するための、ストレージ１０４に関連付けられた１つまたは複数のコントローラ１２２４を含んでもよい。例えば、コントローラ１２２４は、ＲＡＩＤ構成などでアレイ１２２６を構成するため、および／またはストレージデバイス１２２８に基づいて論理ユニットを記憶プログラム１２２２に提示するため、および基礎となる物理ストレージデバイス１２２８上に記憶されたデータオブジェクト１２３０などのデータを管理するためなど、アレイ１２２６を制御してもよい。データオブジェクト１２３０は、ファイルコンテンツ、ファイルメタデータ、および本明細書で議論する他のデータに対応してもよい。ストレージデバイス１２２８は、ハードディスクドライブ、ソリッドステートドライブ、光ドライブ、磁気テープ、それらの組み合わせなどの任意のタイプのストレージデバイスであってもよい。いくつかの例では、１つまたは複数のアレイ１２２６がオンデマンド記憶容量を提供するように構成されたシンプロビジョニングアレイを含んでもよい。さらに、図１２の例は、１つまたは複数のサービスコンピューティングデバイス１０２およびストレージ１０４の可能な構成の一例にすぎない。本明細書の開示の恩恵を受ける当業者には、多くの他の構成が明らかであろう。

図１３は、いくつかの実施形態に係る例示的なクライアントデバイス１０８の例示的なコンポーネントの選択を示す。各クライアント・コンピューティング・デバイス１０８は、ワークステーション、デスクトップ、ラップトップ、タブレットコンピューティングデバイス、モバイルデバイス、スマートフォン、ウェアラブルコンピューティングデバイス、またはネットワークを介してデータを送受信することができる任意の他のタイプのコンピューティング等の任意の適切な種類のコンピューティングデバイスであってよい。さらに、クライアントコンピューティングデバイス１０８は、１つまたは複数のネットワーク１０６を介して、別個のネットワークを介して、または任意の他の適切なタイプの通信接続を介して、１つまたは複数のサービスコンピューティングデバイス１０２と通信することができてもよい。本明細書の開示の恩恵を受ける当業者には、多くの他の変形例が明らかであろう。

基本的な構成では、クライアントデバイス１０８が少なくとも１つのプロセッサ１３０２、１つまたは複数のコンピュータ可読媒体１３０４、１つまたは複数の通信インターフェース１３０６、および１つまたは複数の入出力（Ｉ／Ｏ）コンポーネント１３０８などのコンポーネントを含む。各プロセッサ１３０２は、それ自体、１つまたは複数のプロセッサまたは処理コアを備えてもよい。例えば、各プロセッサ１３０２は、１つまたは複数のマイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、中央処理装置、ステートマシーン、論理回路、および／または動作命令に基づいて信号を操作する任意のデバイスとして実装されてもよい。場合によっては、プロセッサ１３０２が本明細書で説明するプロセスおよび他のアルゴリズムを実行するように特にプログラムまたは構成された任意の適切なタイプの１つまたは複数のハードウェアプロセッサおよび／または論理回路を含んでもよい。プロセッサ１３０２はコンピュータ可読媒体１３０４に格納されたコンピュータ可読プロセッサ実行可能命令をフェッチし、実行するように構成されてもよい。

クライアントデバイス１０８の構成に応じて、コンピュータ可読媒体１３０４は、有形の非一時的コンピュータ可読媒体の一例であってもよく、コンピュータ可読プロセッサ実行可能命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意のタイプの技術で実装された揮発性および不揮発性メモリ、および／またはリムーバブルおよび非リムーバブル媒体を含んでもよい。コンピュータ可読媒体１３０４はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、ソリッドステートストレージ、光ストレージ、磁気ディスクストレージ、磁気テープ、および／または他のタイプのストレージ技術を含んでもよいが、これらに限定されない。さらに、場合によっては、クライアントデバイス１０８が直接、別のコンピューティングデバイスを介して、またはネットワークを介してなど、外部ストレージにアクセスしてもよい。したがって、コンピュータ可読媒体１３０４は、プロセッサ１３０２によって実行され得る命令、プログラム、またはソフトウェアコードを格納することが可能なコンピュータ記憶媒体であってもよい。

コンピュータ可読媒体１３０４は、プロセッサ１３０２によって実行可能な任意の数の機能コンポーネントを格納し、維持するために使用されてもよい。いくつかの実装形態では、これらの機能コンポーネントは、プロセッサ１３０２によって実行可能であり、実行されると、クライアントデバイス１０８に帰属するアクションおよびサービスを実行するための動作ロジックを実装する命令またはプログラムを備える。コンピュータ可読媒体１３０４に格納されたクライアントデバイス１０８の機能コンポーネントは、上述のように、クライアントアプリケーション１２０およびデータ同期サービス１２２を含んでもよい。追加の機能コンポーネントは、クライアントデバイス１０８の様々な機能を制御および管理し、クライアントデバイス１０８との基本的なユーザ対話を可能にするためのオペレーティングシステム１３１０を含んでもよい。いくつかの例では、クライアントアプリケーション１２０は、ファイルシステムフィルタドライバ１３１２、または上述のようにスタブファイルに向けられたファイルアクセス要求を傍受するためにオペレーティングシステムと対話することができる同様のコンポーネントを含んでもよく、またはそれにアクセスできてもよい。コンピュータ可読媒体１３０４は、様々な機能およびタスクを実行するためにクライアントデバイス１０８上で実行することができる１つまたは複数のアプリケーション１３１４をさらに含んでもよい。

さらに、コンピュータ可読媒体１３０４は、機能コンポーネントによって使用されるデータ、データ構造などを格納してもよい。例えば、コンピュータ可読媒体１３０４によって格納されるデータおよびデータ構造は、１つまたは複数のトークン１２８、１つまたは複数のファイルシステム１２４、ストレージ管理ポリシー１３１６、ファイル同期情報１３１８、データＡＰＩ１５４、スタブデータ構造２００、およびユーザのプロファイル情報４０２を含んでもよい。クライアントデバイス１０８のタイプに応じて、コンピュータ可読媒体１３０４は、プログラム、ドライバなどを含むことができる他のモジュールおよびデータ１３２２、ならびに機能コンポーネントによって使用または生成されるデータなど、他の機能コンポーネントおよびデータも任意選択で含んでもよい。さらに、クライアントデバイス１０８は、多くの他の論理的、プログラム的、および物理的コンポーネントを含んでもよく、それらの説明は、本明細書の説明に関連する例にすぎない。

クライアントデバイス１０８は、１つまたは複数の通信インターフェース１３０６をさらに含むことができる。通信インターフェース１３０６は、ネットワーク１０５および１０６を介するなど、様々な他のデバイスとの通信を可能にするための１つまたは複数のインターフェースおよびハードウェアコンポーネントを含んでもよい。したがって、通信インターフェース１３０６は、ストレージシステム１０４と通信するためのネットワーク１０５への接続を提供する１つまたは複数のポートと、サービスコンピューティングデバイス１０２または他のコンピューティングデバイスと通信するためのネットワーク１０６への接続を提供する１つまたは複数のポートとを含んでもよく、またはそれらに接続してもよい。例えば、通信インターフェース１３０６は、本明細書の他の場所にさらに列挙されている通り、ＬＡＮ(ローカルエリアネットワーク）、ＷＡＮ(ワイドエリアネットワーク）、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えば、Ｗｉ−Ｆｉ）および有線ネットワーク（例えば、ファイバチャネル、光ファイバ、イーサネット）、直接接続、ならびにＢＬＵＥＴＯＯＴＨ（登録商標）などの短距離通信などの少なくとも一つまたは複数を介して通信ができればよい。

クライアントデバイス１０８はスピーカ、マイクロフォン、カメラ、および様々なユーザコントロール（例えば、ボタン、ジョイスティック、キーボード、キーパッド、タッチスクリーンなど）、触覚出力デバイスなどのＩ／Ｏコンポーネント１３０８をさらに含んでもよい。例えば、クライアントデバイス１０８のオペレーティングシステム１３１０は、キーパッド、キーボード、またはＩ／Ｏコンポーネント１３０８に含まれる他のユーザコントロールおよびデバイスからの入力を受け入れるように構成された適切なドライバを含んでもよい。加えて、クライアントデバイス１０８は、受動的、放射的、または任意の他の形態のディスプレイであってもよいディスプレイ１３２４を含んでもよい。さらに、クライアントデバイス１０８は図示されていない様々な他のコンポーネントを含むことができ、その例は、様々なタイプのセンサ、全地球測位システムデバイス、バッテリおよび電力制御ユニットなどの電源などを含む。

本明細書で説明される様々な命令、プロセス、および技法は、コンピュータ可読媒体上に格納され、本明細書のプロセッサによって実行されるプログラムモジュールなど、コンピュータ実行可能命令の一般的な文脈で考慮されてよい。一般に、プログラムモジュールは、特定のタスクを実行するため、または特定の抽象データ型を実装するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造、実行可能コードなどを含んでもよい。これらのプログラムモジュールなどは、ネイティブコードとして実行されてもよく、または仮想マシンまたは他のジャストインタイムコンパイル実行環境などでダウンロードされ実行されてもよい。典型的には、プログラムモジュールの機能が様々な実装において所望に応じて組み合わせるか、または分散させることができる。これらのモジュールおよび技法の実装は、コンピュータ記憶媒体上に格納されるか、または何らかの形態の通信媒体を介して送信されてもよい。

主題は、構造的特徴および／または方法論的動作に特有の言葉で説明されてきたが、添付の特許請求の範囲で定義される主題は説明される特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、特定の特徴および動作は、特許請求の範囲を実施する例示的な形態として開示される。

Claims (14)

1. サービスコンピューティングデバイスと、ネットワークを介して前記サービスコンピューティングデバイスと通信可能なクライアントデバイスとを備えるシステムであって、
   前記クライアントデバイスは、
   １つまたは複数のプロセッサと、
   １つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサを、操作を実行するように構成する実行可能命令を維持する１つまたは複数の非一時的なコンピュータ可読媒体と有し、
   前記操作は、
   前記クライアントデバイスによって、前記クライアントデバイスに関連付けられたファイルシステムへの変更に関連する情報の要求を、前記サービスコンピューティングデバイスに送信すること、
   前記クライアントデバイスによって、前記サービスコンピューティングデバイスから、前記ファイルシステムに対する１つまたは複数の変更のリストを受信すること、
   受信した１つまたは複数の変更における少なくとも一部に基づいて、前記クライアントデバイス上のスタブファイルのメタデータを追加することまたは更新することのうちの少なくとも１つを含み、前記スタブファイルは、前記クライアントデバイス上に格納されたスタブデータ構造を含み、
   前記スタブファイルのファイルコンテンツは、ネットワーク上のストレージに格納され、
   前記スタブファイルの前記メタデータを追加することまたは更新することは、前記スタブデータ構造に関連付けてハッシュ値を格納することを含み、
   前記ハッシュ値は、前記スタブファイルの前記ファイルコンテンツの最新バージョンに基づいており、前記ハッシュ値は、前記ファイルシステムに対する１つまたは複数の変更のリストと共に受信される、
   システム。
2. 前記スタブデータ構造は、
   前記スタブファイルを生成するために使用されたソフトウェアのソフトウェアバージョンインジケータ、または、スタブファイルに対応するファイルのファイルコンテンツが前記クライアントデバイス上のローカルストレージに格納されているかどうかに関するインジケータの少なくとも１つをさらに含む、
   請求項１に記載のシステム。
3. 前記スタブファイルの前記メタデータを追加すること、または更新することは、前記ファイルシステム内の前記スタブファイルのメタデータ値を追加することまたは更新することを含み、前記メタデータ値は、ファイルサイズ、ファイル修正時間、ファイルパス、またはファイルバージョンのうちの少なくとも１つを含む、
   請求項１に記載のシステム。
4. 前記情報の要求を送信することは、前記要求と共にトークンを送信することを含み、前記トークンは前記ファイルシステムのファイルシステム識別子と、前記クライアントデバイスによって処理されたファイルシステムの変更を識別するトランザクション識別子とを含む、
   請求項１に記載のシステム。
5. 前記トークンは、前記ファイルシステムに対する１つまたは複数の変更についての以前のリストとともに、前記サービスコンピューティングデバイスから受信され、前記操作は、前記ファイルシステムに対する１つまたは複数の変更の前記リストとともに、更新されたトランザクション識別子を含む他のトークンを受信することをさらに含む、
   請求項４に記載のシステム。
6. 前記操作は、
   前記サービスコンピューティングデバイスにおいて、前記ファイルシステムを通知サービスに登録することと、
   前記クライアントデバイスによって、前記クライアントデバイスに関連付けられたファイルシステムへの変更の指示を前記通知サービスから受信することと、をさらに含む、
   請求項１に記載のシステム。
7. 前記操作は、
   前記通知サービスに、前記ファイルシステムに対する変更の通知の要求を、前記通知サービスに送信することを含み、前記要求は、トークンを含み、前記トークンは、ファイルシステム識別子と、前記クライアントデバイスによって処理されたファイルシステムの変更を識別するトランザクション識別子とを含み、
   更に、前記クライアントデバイスによって、前記通知サービスに送信された前記要求の少なくとも一部に基づいて、前記ファイルシステムに対する変更の指示を通知サービスから受信することを含む、
   請求項６に記載のシステム。
8. 前記操作は、
   前記クライアントデバイス上で、前記スタブファイルに対応するファイルのファイルコンテンツにアクセスする要求を受信することと、
   前記ファイルコンテンツを取り出すための要求を前記サービスコンピューティングデバイスに送信することと、
   前記ファイルコンテンツを前記クライアントデバイスで受信することと、
   前記クライアントデバイス上で前記ファイルコンテンツにアクセスする要求に応答して、前記ファイルコンテンツを提供することと、をさらに含む、
   請求項１に記載のシステム。
9. 前記操作は、
   前記クライアントデバイスにおけるユーザ入力に基づいて、前記ファイルコンテンツに対する少なくとも１つの変更を受信することと、
   少なくともストレージ管理ポリシーに基づいて、前記ファイルが前記クライアントデバイス上の前記スタブファイルとして維持されるべきであることを決定することと、
   前記ファイルコンテンツに対する少なくとも１つの変更を、ネットワークを介して前記サービスコンピューティングデバイスと同期させることと、
   前記ファイルコンテンツに対する少なくとも１つの変更に基づいて、前記スタブデータ構造内に更新されたハッシュ値を格納することと、
   前記ファイルコンテンツが前記クライアントデバイス上のローカルストレージから削除されるべきであることを示すことと、をさらに含む、
   請求項８に記載のシステム。
10. 前記操作は、
    前記ファイルシステムに対する１又は複数の変更のリストが、前記ファイルシステムにファイルを追加するための、他のクライアントデバイスによる前記スタブファイルに対応する前記ファイルの前記ファイルコンテンツの生成を含むことを決定することをさらに含み、
    前記クライアントデバイス上で前記スタブファイルの前記メタデータを追加することまたは更新することは、前記サービスコンピューティングデバイスから受信された１つまたは複数の変更のリストに基づいて、前記スタブデータ構造を生成することと、前記ファイルシステムに前記スタブファイルのメタデータを追加することとを含む、
    請求項１に記載のシステム。
11. 前記操作は、
    前記ファイルシステムに対する１つまたは複数の変更のリストが、他のクライアントデバイスによって作成された前記スタブファイルに対応するファイルの前記ファイルコンテンツに対する変更を含むことを決定することをさらに含み、
    前記クライアントデバイス上で前記スタブファイルの前記メタデータを追加することまたは更新することは、前記サービスコンピューティングデバイスから受信された１つまたは複数の変更のリストに基づいて、前記スタブデータ構造に前記変更されたファイルコンテンツの更新されたハッシュ値を追加することと、前記ファイルシステム内の前記スタブファイルのメタデータのメタデータ値を更新することとを含む、
    請求項１に記載のシステム。
12. 前記操作は、
    前記ファイルシステムに対する１つまたは複数の変更のリストが、他のクライアントデバイスによる前記スタブファイルに対応するファイルの前記ファイルシステムからの削除を含むことを決定することをさらに含み、
    前記クライアントデバイス上で前記スタブファイルの前記メタデータを追加することまたは更新することは、前記ファイルシステムから、前記スタブデータ構造および前記スタブファイルのメタデータを削除することを含む、
    請求項１に記載のシステム。
13. クライアントデバイスによって、前記クライアントデバイスに対応するファイルシステムに対する変更に関連する情報の要求を、ネットワークを介してサービスコンピューティングデバイスに送信し、
    前記クライアントデバイスによって、前記サービスコンピューティングデバイスから、前記ファイルシステムに対する１つまたは複数の変更のリストを受信し、
    前記受信した１つまたは複数の変更における少なくとも一部に基づいて、前記クライアントデバイス上のスタブファイルのメタデータを追加し、または更新することの一方を行い、
    前記スタブファイルは、前記クライアントデバイス上に格納されたスタブデータ構造を含み、
    前記スタブファイルのファイルコンテンツは、前記ネットワーク上のストレージに格納され、
    前記スタブファイルの前記メタデータを追加することまたは更新することは、前記スタブデータ構造に関連付けてハッシュ値を格納することを含み、
    前記ハッシュ値は、前記スタブファイルの前記ファイルコンテンツの最新バージョンに基づいており、前記ハッシュ値は、前記ファイルシステムに対する１つまたは複数の変更のリストと共に受信される
    方法。
14. 命令を格納する１つまたは複数の非一時的なコンピュータ可読媒体であって、
    前記命令は、クライアントデバイスの１つまたは複数のプロセッサによって実行されると、
    前記１つまたは複数のプロセッサを、
    前記クライアントデバイスによって、前記クライアントデバイスに対応するファイルシステムに対する変更に関連する情報の要求を、ネットワークを介してサービスコンピューティングデバイスに送信し、
    前記クライアントデバイスによって、前記サービスコンピューティングデバイスから、前記ファイルシステムに対する１つまたは複数の変更のリストを受信し、
    前記受信した１つまたは複数の変更における少なくとも一部に基づいて、前記クライアントデバイス上のスタブファイルのメタデータを追加し、または更新することの一方を行うようにプログラムし、
    前記スタブファイルは、前記クライアントデバイス上に格納されたスタブデータ構造を含み、
    前記スタブファイルのファイルコンテンツは、前記ネットワーク上のストレージに格納され、
    前記スタブファイルの前記メタデータを追加することまたは更新することは、前記スタブデータ構造に関連付けてハッシュ値を格納することを含み、
    前記ハッシュ値は、前記スタブファイルの前記ファイルコンテンツの最新バージョンに基づいており、前記ハッシュ値は、前記ファイルシステムに対する１つまたは複数の変更のリストと共に受信される
    コンピュータ可読媒体。