(57)【特許請求の範囲】
【請求項１】
データ処理システムにおける装置において、
システム内の複数のデータ項目のいずれかについて、少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される実質的にユニークな識別子であって、前記識別子はデータ項目のデータの全部およびデータ項目のデータにのみ依存するものを決定する識別手段と、
システム内に特定のデータ項目が存在するかどうかを、複数のデータ項目の識別子を調べることにより決定するための存在手段と
を備えたことを特徴とする装置。
【請求項２】
請求項１記載の装置において、特定のデータ項目のインスタンスが、データ項目の識別子に基づいて、システム内の特定のロケーションに存在するか否かを決定するローカル存在手段をさらに備えたことを特徴とする装置。
【請求項３】
請求項２記載の装置において、各ロケーションは別個の複数のデータ項目を含み、前記ローカル存在手段は特定のデータ項目がシステム内の特定のロケーションに存在するか否かをシステム内の前記特定のロケーションの複数のデータ項目の識別子を調べることにより決定することを特徴とする装置。
【請求項４】
請求項２記載の装置において、システム内のデータ項目について、データ項目とデータ項目の識別子との間の関連を作り維持するデータ関連付け手段と、
データ項目の識別子を使用して特定のデータ項目にアクセスするアクセス手段と
をさらに備えたことを特徴とする装置。
【請求項５】
請求項２記載の装置において、データ処理システムにおけるソースから宛先へデータ項目をコピーし、データ項目が宛先に存在しないことをデータ識別子を用いて決定する場合にのみデータ項目を前記宛先に提供することによる複製手段をさらに備えたことを特徴とする装置。
【請求項６】
請求項４記載の装置において、システムに新規データ項目をアシミレートするアシミレーション手段であって、前記アシミレーション手段は前記識別手段を起動して新規データ項目の識別子を決定しかつ前記データ関連付け手段を起動して新規データ項目をその識別子と関連付けるものをさらに備えたことを特徴とする装置。
【請求項７】
請求項４記載の装置において、データ項目をソース・ロケーションからデータ処理システムにおける宛先ロケーションへ、データ項目の識別子に基づいて複裂する複製手段であって、前記複製手段は前記ローカル存在手段を起動してデータ項目のインスタンスが宛先ロケーションに存在するか否かを決定し、データ項目のインスタンスが宛先に存在しないことを前記ローカル存在手段が決定する場合にだけ前記アクセス手段を起動して前記宛先にデータ項目を提供するものをさらに備えたことを特徴とする装置。
【請求項８】
請求項７記載の装置において、システムにデータ項目のコピーを作成するバックアップ手段であって、前記バックアップ手段はバックアップしたデータ項目の識別子のバックアップ・レコードを保持し、複製手段を起動してデータ識別子がバックアップ・レコードに記録されていないデータ項目のみをコピーするものをさらに備えたことを特徴とする装置。
【請求項９】
請求項８記載の装置において、前記バックアップ手段によって以前にバックアップされたデータ項目をデータ項目の識別子に基づいて取り出す復元手段であって、前記復元手段はバックアップ・レコードを用いてデータ項目を識別し、アクセス手段を起動してデータ項目を取り出すものをさらに備えたことを特徴とする装置。
【請求項１０】
請求項２記載の装置において、ロケーションはコンピュータのネットワーク内のコンピュータであって、該装置は、
データ項目がシステム内の現在の位置からシステム内のリモート・ロケーションに存在するか否かを、データ項目の識別子に基づいて決定し、前記リモート・ロケーションはローカル存在手段をリモート・ロケーションで用いてデータ項目がリモート・ロケーションに存在するか否かを決定し、リモート・ロケーションでデータ項目の存在の表示を現在のロケーションに提供するリモート存在手段をさらに備えたことを特徴とする装置。
【請求項１１】
請求項４記載の装置において、ロケーションはコンピュータのネットワーク内のコンピュータであって、該装置は、
システムのリモート・ロケーションからシステム内の現在のロケーションにあるデータ項目を、データ項目の識別子に基づいて要求し、前記リモート・ロケーションはアクセス手段をリモート・ロケーションで用いてデータ項目を取得し、存在する場合は現在のロケーションにこれを送信する要求手段をさらに備えたことを特徴とする装置。
【請求項１２】
請求項１記載の装置において、システム内のデータ項目の少なくともひとつのコンテクスト名とデータ項目の識別子との間のコンテクスト関連性を作成し維持するコンテクスト手段と、
データ項目についてコンテクスト名が与えられたシステム内のデータ項目の識別子を、前記コンテクスト関連性を用いて取得する参照手段と
をさらに備えたことを特徴とする装置。
【請求項１３】
請求項１２記載の装置において、データ項目をコンテクスト名に割り当て、前記識別手段を起動してデータ項目の識別子を決定し、前記コンテクスト手段を起動してデータ項目のコンテクスト名とデータ項目の識別子との間のコンテクスト関連性を作成または変更するための割り当て手段をさらに備えたことを特徴とする装置。
【請求項１４】
請求項１２記載の装置において、
システム内のデータ項目について、データ項目とデータ項目の識別子との間の関連性を作成して維持するデータ関連付け手段と、
特定のデータ項目に、特定のデータ項目の識別子を用いてアクセスするアクセス手段と、
データ項目の与えられたコンテクスト名でシステム内のデータ項目にアクセスし、与えられたコンテクスト名に関連するデータ識別子を決定し、前記アクセス手段を起動してデータ項目にデータ識別子を用いてアクセスするコンテクスト名アクセス手段と
をさらに備えたことを特徴とする装置。
【請求項１５】
請求項１１記載の装置において、数個のロケーションのひとつからデータ項目に、データ項目の識別子を用いてアクセスする透過的アクセス手段であって、前記透過的アクセス手段は前記ローカル存在手段を起動して特定のデータ項目が現在のロケーションに存在するかを決定し、かつ特定のデータ項目が現在のロケーションに存在しない場合には、前記要求手段を起動してリモート・ロケーションからデータ項目を取得するものをさらに備えたことを特徴とする装置。
【請求項１６】
請求項１５記載の装置において、ソース・ロケーションから宛先ロケーションへデータ項目の識別子をコピーする識別子コピー手段をさらに備えたことを特徴とする装置。
【請求項１７】
請求項１５記載の装置において、
システム内のデータ項目のコンテクスト名とデータ項目の識別子との間のコンテクスト関連性を作成し維持するコンテクスト手段と、
ソース・ロケーションから宛先ロケーションへデータ項目をコピーし、データ項目のコンテクスト名が与えられるとコンテクスト識別子とデータ識別子との間のコンテクスト関連性だけをソース・ロケーションから宛先ロケーションへコピーするコンテクスト・コピー手段と、
データ項目を数個のロケーションのシステムからデータ項目についてのコンテクスト名が与えられると取得する透過的参照手段であって、前記透過的参照手段は前記コンテクスト関連付けを起動してコンテクスト名の与えられたデータ項目のデータ識別子を決定し、前記透過的アクセス手段を起動してデータ項目の識別子が与えられた数個のロケーションのひとつからデータ項目にアクセスするものと
をさらに備えたことを特徴とする装置。
【請求項１８】
請求項１記載の装置において、前記データ項目の少なくとも幾つかは複合データ項目であり、各複合データ項目は固定のシーケンスで少なくとも幾つかのコンポーネント・データ項目を含み、識別手段は複合データ項目のコンポーネント・データ項目各々に基づいて複合データ項目の識別子を決定することを特徴とする装置。
【請求項１９】
請求項１８記載の装置において、複前記合データ項目はファイルでありかつ前記コンポーネント・データ項目はセグメントであり、識別手段はファイルの識別子を、ファイルの各データ・セグメントの識別子に基づいて決定することを特徴とする装置。
【請求項２０】
請求項１８記載の装置において、前記複合データ項目はディレクトリでありかつ前記コンポーネント・データ項目はファイルまたは従属ディレクトリであり、識別手段は任意のディレクトリの識別子を任意のディレクトリ内の各々のファイルおよび従属ディレクトリに基づいて決定することを特徴とする装置。
【請求項２１】
請求項１１記載の装置において、システム内のロケーションからシステム内の少なくともひとつの他のロケーションへデータ項目をアドバタイズする手段であって、前記アドバタイズする手段は前記少なくともひとつの他のロケーションの各々にデータ項目のデータ識別子を提供し、かつ前記他のロケーションのうちで前記提供に応答して前記データ項目を要求するロケーションにのみデータ項目を提供するものをさらに備えたことを特徴とする装置。
【請求項２２】
請求項１８記載の装置において、特定のデータ項目がシステム内の特定のロケーションに存在するか否かを、データ項目の識別子に基づいて決定するローカル存在手段と、
データ処理システム内でソースから宛先へデータ項目をコピーする複合コピー手段であって、前記複合コピー手段は前記ローカル存在手段を起動してデータ項目が宛先に存在するか否かを決定し、かつデータ項目が複合データ項目の場合に、複合データ項目のコンポーネント・データ項目が宛先に存在するか否かを決定し、データ項目が宛先に存在しないと前記ローカル存在手段が決定した時にだけデータ項目を前記宛先に提供し、コンポーネント・データ項目が宛先に存在しないと前記ローカル存在手段が決定した時にだけ各コンポーネント・データ項目を前記宛先に提供するものと
をさらに備えたことを特徴とする装置。
【請求項２３】
請求項１１記載の装置において、前記要求に特定のデータ識別子を提供することに応答して前記要求手段から取得したデータ項目の完全性を検証して、要求手段から取得したデータ項目が要求したデータ項目と同一のデータ項目であることを確認する検証手段であって、前記検証手段は前記識別手段を起動して取得したデータ項目のデータ識別子を決定し、前記決定したデータ識別子を前記特定のデータ識別子と比較して前記取得したデータ項目を検証するものをさらに備えたことを特徴とする装置。
【請求項２４】
請求項２記載の装置において、ロケーションは記憶ロケーションと処理ロケーションの少なくとも一方であり、記憶ロケーションはデータ記憶装置とデータ記憶ボリュームの少なくとも一方であり、処理ロケーションはデータ・プロセッサとコンピュータの少なくとも一方であることを特徴とする装置。
【請求項２５】
請求項３記載の装置において、前記データ項目の少なくとも幾つかは複合データ項目であり、各複合データ項目は固定シーケンスで少なくとも幾つかのコンポーネント・データ項目を含み、識別手段は複合データ項目の識別子を複合データ項目の各コンポーネント・データ項目の識別子に基づいて決定することを持徴とする装置。
【請求項２６】
請求項３記載の装置において、
システム内の全てのデータ項目について、データ項目の識別子とシステム内の持定のロケーションにおけるデータ項目の少なくともひとつのコンテクスト名との間のコンテクスト関連性を作成し維持するコンテクスト関連付け手段と、
システム内の特定のロケーションにおいてデータ項目についてのコンテクスト名が与えられたシステム内のデータ項目の識別子を取得する手段と、
ソース・ロケーションにおけるコンテクスト名に対応するデータ識別子をデータ処理システム内の宛先ロケーションにおけるコンテクスト名に関連付けるための論理コピー手段と
をさらに備えたことを特徴とする装置。
【請求項２７】
請求項２５記載の装置において、前記複合データ項目はファイルでありかつ前記コンポーネント・データ項目はセグメントであり、識別手段はファイルの識別子をファイルの各データ・セグメントの識別子に基づいて決定することを特徴とする装置。
【請求項２８】
請求項２５記載の装置において、データ項目をデータ処理システムにおけるソース・ロケーションから宛先ロケーションへコピーする複合コピー手段であって、前記複合コピー手段はぜローカル存在手段を起動してデータ項目が宛先に存在するか否かを決定し、かつデータ項目が複合データ項目の場合に、複合データ項目のコンポーネント・データ項目が宛先に存在するか否かを決定し、データ項目が宛先に存在しないと前記ローカル存在手段が決定した場合にのみデータ項目を前記宛先に提供し、コンポーネント・データ項目が宛先に存在しないと前記ローカル存在手段が決定した場合にのみ各コンポーネント・データ項目を前記宛先に提供するものをさらに備えたことを特徴とする装置。
【請求項２９】
請求項１ないし２８いずれかに記載の装置において、データ項目はファイル、データベース・レコード、メッセージ、データ・セグメント、データブロック、ディレクトリ、オブジェクトクラスのインスタンスの少なくともひとつであることを特徴とする装置。
【請求項３０】
データ処理システムにおけるデータ項目を該データ項目への引き続くアクセスのために識別する方法において、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目に実質的にユニークな識別子を決定し、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
データ項目の識別子を用いてシステム内のデータ項目にアクセスするステップと
を備えたことを特徴とする方法。
【請求項３１】
請求項３０に記載の方法において、システム内の複数のデータ項目について、各々のデータ項目とデータ項目の各々の識別子との間の関連性を作り維持するステップをさらに備え、前記アクセスするステップは関連性を介してデータ項目にアクセスすることを特徴とする方法。
【請求項３２】
請求項３１記載の方法において、新規データ項目の識別子を決定して新規データ項目をその識別子に関連付けることにより、新規データ項目をシステムにアシミレートするステップをさらに備えたことを特徴とする方法。
【請求項３３】
データ処理システム内のソース・ロケーションから宛先ロケーションへ任意のデータ項目を複製する方法において、該方法は、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、任意のデータ項目について実質的にユニークな識別子を決定し、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
前記データ識別子を用いて、前記宛先ロケーションに前記データ項目が存在するか否かを決定するステップと、
前記決定に基づいて、前記データ項目が前記宛先に存在しない場合にのみ前記データ項目を前記宛先ロケーションに提供するステップと
を備えたことを特徴とする方法。
【請求項３４】
請求項３３記載の方法において、前記任意のデータ項目は複数のコンポーネント・データ項目を有する複合データ項目であり、該方法は、
前記コンポーネント・データ項目の各々のデータ項目について、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目について実質的にユニークな識別子を決定することによりデータ項目のコンポーネント・データ識別子を取得するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
前記取得したコンポーネント・データ識別子を用いて、前記データ項目が前記宛先に存在するか否かを決定するステップと、
前記決定に基づいて、前記データ項目が前記宛先に存在しない場合にのみ前記データ項目を前記宛先に提供するステップと
をさらに備えたことを特徴とする方法。
【請求項３５】
データ処理システムに特定のデータ項目が存在するか否かを決定する方法であって、該方法は、
（Ａ）システム内の複数のデータ項目の各データ項目について、
（i）少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目について実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
（ii）前記複数のデータ項目の識別子の組を作成し維持するステップと、
（Ｂ）特定のデータ項目について
（i）少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目について特定の実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
（ii）前記特定の識別子が前記データ項目の組にあるか否かをを決定するステップと
を備えたことを特徴とする方法。
【請求項３６】
複数のデータ項目のうちで、データ処理システムにおける前回のバックアップ時刻以降に変更されたデータ項目をバックアップする方法において、
（Ａ）前回のバックアップ時刻にバックアップされたデータ項目の識別子のバックアップ・レコードを保持するステップと、
（Ｂ）前記複数のデータ項目の各々について
（i）少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目について実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
（ii）識別子がバックアップ・レコードに無い複数のデータ項目のうちのデータ項目を決定するステップと、
（iii）前記決定に基づいて、データ識別子がバックアップ・レコードに記録されていないデータ項目だけをコピーするステップと
を備えたことを特徴とする方法。
【請求項３７】
請求項３６記載の方法において、バックアップ・レコードに前記コピーのステップにおいてコピーされたデータ項目の識別子を記録するステップをさらに備えたことを特徴とする方法。
【請求項３８】
データ処理システムのロケーションで特定のデータ項目に位置づける方法において、該方法は、
（Ａ）少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目に実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
（Ｂ）データ項目のデータ識別子を要求側ロケーションからシステム内の複数の提供側ロケーションの少なくともひとつのロケーションへ送信することにより特定のデータ項目を要求するステップと、
（Ｃ）前記提供側ロケーションの少なくとも幾つかにおいて、
（a）前記提供側ロケーションでの複数のデータ項目の各々のデータ項目について、
（i）少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目に実質的にユニークな識別子を決定し、識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
（ii）データ項目の識別子の組を作成し維持するステップと、
（b）前記識別子の組に基づいて、要求されたデータ識別子に対応するデータ項目が前記提供側ロケーションに存在するか否かを決定するステップと、
（c）前記決定に基づいて、特定のデータ項目が提供側ロケーションに存在すると前記提供側ロケーションが決定した場合、提供側が与えられたデータ項目のコピーを有することを前記要求側に通知するステップと
を備えたことを特徴とする方法。
【請求項３９】
請求項３８記載の方法において、
（ａ）前記提供側ロケーションにおいて複数のデータ項目の各々のデータ項目について、
データ項目とデータ項目の識別子との間の関連性を作成し維持するステップと、
（ｂ）前記通知に応答して、前記応答するリモート・ロケーションのひとつから前記クライアント・ロケーションは前記データ項目をコピーし、前記関連性を用いてデータ識別子が与えられたデータ項目をアクセスするステップと
を備えたことを特徴とする方法。
【請求項４０】
複数のロケーションの内で特定のデータ項目に位置づける方法において、前記ロケーションの各々は複数のデータ項目を有し、該方法は、
特定のデータ項目についておよび複数のデータ項目の各々のデータ項目について、少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データ項目に実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
特定のデータ項目の識別子が前記ロケーションの各々に存在するか否かを決定することにより前記複数のロケーションの各々における特定のデータ項目の存在を決定するステップと
を備えたことを特徴とする方法。
【請求項４１】
請求項３０記載の方法において、前記アクセスするステップはさらに、任意のデータ識別子についておよびシステム内の任意の現在ロケーションおよびリモート・ロケーションについて、
任意のデータ識別子に対応するデータ項目が現在のロケーションに存在するか否かを決定するステップと、
前記決定に基づいて、前記データ項目が現在のロケーションに存在しない場合、システム内のリモート・ロケーションから現在のロケーションへデータ項目をフェッチするステップと
を備えたことを特徴とする方法。
【請求項４２】
請求項４１記載の方法において、
ロケーションにおける各々のコンテクスト名について、
データ項目のコンテクスト名と前記データ項目の識別子との間で、および何らかのコンテクスト関連性が前記現在のロケーションで変化した場合に、コンテクスト関連性を作成し維持するステップと、
コンテクスト関連性への変更を前記リモート・ロケーションに通知するステップと
を備えたことを特徴とする方法。
【請求項４３】
請求項４２記載の方法において、リモート・ロケーションで、データ項目のコンテクスト識別子とデータ項目の識別子との間の関連性を更新するステップをさらに備えたことを特徴とする方法。
【請求項４４】
請求項４３記載の方法において、前記リモート・ロケーションから他の全てのロケーションに前記データ項目が変更されたことを、前記データ項目のコンテクスト識別子とデータ識別子とを前記他のロケーションに提供することにより通知するステップをさらに備えたことを特徴とする方法。
【請求項４５】
請求項４４記載の方法において、データ項目が変更されたことを通知された各ロケーションにおいて、
データ項目のコンテクスト識別子とデータ項目のデータ識別子との間の関連性を変更して、データ項目が変更されたことを記録するステップをさらに備えたことを特徴とする方法。
【請求項４６】
データ処理システム内の任意のロケーションで、システムの別のロケーションからデータ項目を取得できる場合に、データ項目を除去する方法において、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データに実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
データ識別子と前記データ項目が存在することが分かっている少なくともひとつのロケーションとの間のソース関連性を作成し維持するステップと、
前記ソース関連性に基づいて、前記データ項目が前記他のロケーションに存在する場合、任意のロケーションからデータ項目を削除するステップと
を備えたことを特徴とする方法。
【請求項４７】
データ処理システム内のロケーションからデータ項目を消去する方法において、該方法は、
システム内の複数のデータ項目の各々について、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データに実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
各々のデータ項目とデータ項目のユニークな識別子との間の関連性を作成し維持するステップと、
任意のデータ項目について、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データに実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
コンテクスト識別子または複合データ項目またはシステム内のリモート・プロセッサがデータ項目のユニークな識別子を参照するか否かを決定し、前記決定に基づいて、他のコンテクスト識別子または複合データ項目またはリモート・プロセッサが前記データ項目を参照しない場合に前記データ項目およびその関連性を消去するステップと
を備えたことを特徴とする方法。
【請求項４８】
請求項４７記載の方法において、前記決定はデータ項目についての使用カウントに基づくものであり、他のコンテクスト識別子または複合データ項目またはシステム内のリモート・プロセッサがデータ項目を参照しないことが前記使用カウントで示される場合にのみ前記データ項目は消去されることを特徴とする方法。
【請求項４９】
データ処理システム内のクライアント・ロケーションでデータ項目を実質的に同期する方法において、クライアントとシステム内の別のロケーションでの独立した変化の期間の後で、コンテクストが与えられ、該方法は、
少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データに実質的にユニークな識別子を決定するステップであって、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存するステップと、
データ項目の各コンテクスト名と前記データ項目の識別子との間のコンテクスト関連性への変更のリストを、与えられたコンテクストにおいておよび独立した変化の期間中に作成し維持するステップと、
与えられたコンテクストについて他のロケーションから変化のリストを取得するステップと、
変化のリストのコンテクスト名の各々について、
与えられたコンテクスト名のコンテクスト関連性が、独立した変化の場合の期間にクライアントだけまたは他のロケーションだけのどちらで変化したか決定された場合にはいつでも、クライアントでコンテクスト識別子の関連性を更新するステップと、
コンテクスト関連性がクライアントと他のロケーションの両方で変化したと決定された場合にはいつでも、クライアント・ロケーションのオペレータに通知する等の競合解消タスクを実行するステップと
を備えたことを特徴とする方法。
【請求項５０】
請求項４９記載の方法において、前記リストは一時的順序に基づいたキューとして維持され、前記クライアント・ロケーションにおいて、前記置き換えは前記一時的順序に基づくことを特徴とする方法。
【請求項５１】
データ処理システムにおける任意のデータ項目の少なくとも所定の個数のコピーを、前記データ処理システム内の異なるロケーションに維持する方法において、前記データ処理システムは、少なくとも一部はメッセージ・ダイジェスト関数を用いて計算される、データが実質的にユニークな識別子によって識別されるシステムであり、前記識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存し、システム内のあらゆるデータ項目はデータ項目の識別子のみを使用してアクセスされ、該方法は、
（i）システム内の第１のロケーションから、システム内の他のロケーションへ任意のデータ項目のデータ識別子を送信するステップと、
（ii）前記送信に応答して、前記他のロケーションの各々で、
（A）データ識別子に対応するデータ項目が他のロケーションに存在するか否かを決定するステップと、前記決定に基づいて、
（B）前記データ項目が他のロケーションに存在するか否かを前記第１のロケーションに通知するステップと、
（iii）前記他のロケーションからの前記通知に応答して、前記第１のロケーションで、
（A）前記データ項目が少なくとも所定数の他のロケーションに存在するか否かを決定するステップと、前記決定に基づいて、
（B）所定数より少ない他のロケーションがデータ頂目のコピーを有する場合、データ項目のコピーを有していない幾つかのロケーションにデータ項目のコピーを作成するように要求するステップと
を備えたことを特徴とする方法。
【請求項５２】
請求項５１記載の方法において、前記ステップ（ｉｉｉ）はさらに、
（Ｃ）所定数より多い他のロケーションがデータ項目のコピーを有する場合、データ項目のコピーを有する幾つかのロケーションにデータ項目のコピーを消去するように要求するステップを備えたことを特徴とする方法。
【請求項５３】
請求項３０ないし５２いずれかに記載の方法において、前記データ項目は、ファイル、データベース・レコード、メッセージ、データ・セグメント、データ・ブロック、ディレクトリ、オブジェクト・クラスのインスタンスの少なくともひとつであることを特徴とする方法。
【発明の詳細な説明】
発明の背景
１．発明の分野
本発明はデータ処理システムに関し、さらに詳しくはデータ項目のデータの全部かつデータ項目内のデータにのみ依存する実質的にユニークな識別子によってデータ項目が識別されるようなデータ処理システムに関する。
２．発明の背景
データ処理（data processing：ＤＰ）システム、コンピュータ、コンピュータ・ネットワーク、その他は一般にユーザやプログラムにシステム内のデータを識別する各種の方法を提供している。
ユーザはデータに何らかの形の名称を付与することでデータ処理システム内のデータを識別するのが一般的である。たとえば、コンピュータにおける典型的なオペレーティング・システム（operating system：ＯＳ）はファイル・システムを提供し、ここでデータ項目は英数字からなる識別子により名前が付けられている。プログラムはロケーションまたはアドレスを用いてデータ処理システム内のデータを識別するのが一般的である。たとえば、あるプログラムはファイルまたはデータベース内のレコードを識別するのにそのレコードに位置づけるために用いられているレコード番号を用いることができる。
全部ではなくとも大半のプリミティブなオペレーティング・システムにおいて、ユーザやプログラムは名前の付けられたデータ項目の集合を作成して使用することができ、これらの集合自体が識別子によって名付けられている。これらの名付けられた集合はそれ自体が他の名前が付けられた集合の一部を構成することもある。たとえば、あるＯＳはファイル（データ項目）をディレクトリ（集合）にグループ化するメカニズムを提供することができる。これらのディレクトリは、それ自体が他のディレクトリの一部を構成することができる。データ項目はこれらの入れ子型（nesting）ディレクトリに対して、名前のシーケンス、または、特定のデータ項目（ファイルまたはディレクトリ）へのディレクトリを通るパスを定義しているいわゆるパス名を用い、相対的に識別される。
別の例として、データベース管理システムはデータ・レコード（データ項目）をテーブルにグループ化してから、これらのテーブルをデータベース・ファイル（集合）にグループ化することができる。あらゆるデータレコードの完全なアドレスはデータベースのファイル名、テーブル名、そのデータ・レコードのレコード番号を用いることで指定することができる。
データ項目を識別する他の例としては、ネットワーク・ファイル・システムにおいてファイルを識別する、オブジェクト指向データベースにおいてオブジェクトを識別する、画像データベースにおいて画像を識別する、テキスト・データベースにおいて記事を識別するなどが挙げられる。
一般に、本明細書で用いているような術語「データ」および「データ項目」はビットのシーケンスを表わす。したがって、データ項目は、ファイルの内容、ファイルの一部、メモリ内のページ、オブジェクト指向プログラムのオブジェクト、ディジタル・メッセージ、ディジタル走査画像、ビデオまたはオーディオ信号の一部、その他ビットのシーケンスで表わすことができる何らかの実体、とすることができる。本明細書において術語「データ処理」はデータ項目の処理を表わし、場合によっては処理しようとするデータの型に依存する。たとえば、ディジタル画像のためのデータ・プロセッサはオーディオ信号のためのデータ・プロセッサとは異なる場合がある。
従来のデータ処理システムの全部において、データ項目（データ項目はファイル、ディレクトリ、データベース内のレコード、オブジェクト指向プログラミングにおけるオブジェクト、メモリ内のロケーション、または物理装置上のロケーション、その他のことがある）を識別するために提供された名前または識別子は常に特定のコンテクストに対して相対的に定義されている。たとえば、特定のファイル名で識別されるファイルはそのファイル（コンテクスト）を含むディレクトリが分かっている場合にだけ特定することができる。パス名で識別されるファイルはファイル・システム（コンテクスト）が分かっている場合にだけ特定できる。同様に、プロセスのアドレス空間内のアドレス、データベース・テーブル内のキー、またはインターネットなどの世界規模のコンピュータ・ネットワークでのドメイン名は、コンテクストに対して相対的に指定されることによってのみ意味をもつ。
データ項目を識別するための従来技術のシステムにおいては、データ名とデータ項目との間に直接の関連性はない。２つの異なるコンテクストで同一のデータ名で異なるデータ項目を表わすことがあり、また同一のコンテクストで異なる２つのデータ名が同一のデータ項目を表わすことがある。
さらに、データ名とこれが参照するデータとの間には相関がないので、任意のデータ項目が実際にデータ名で名付けられるデータなのかを確認する先験的な（a priori）方法はない。たとえば、ＤＰシステムにおいて、ひとつのプロセッサが別のプロセッサに任意のデータ名を有するデータ項目を配信するように要求する場合、要求側プロセッサは、一般に、配信されるデータが正しいデータか確かめようがない（名前だけしか与えられていない）。したがってさらに処理し、典型的には要求側の一部で、取得したデータ項目が本当に要求した項目なのか確認する必要がある。
ＤＰシステムで共通のオペレーション（operation）はシステムに新規データ項目を追加することである。新規データ項目がシステムに追加される場合、名前が定義されるコンテクストを更新することだけで名前を割り当てることができる。したがってこのようなシステムは名前の管理について集中化されたメカニズムを必要とする。このようなメカニズムは、データ項目が離れた場所にある別のプロセッサで作成され識別され、データ項目が追加される場合に通信する必要がないような場合にマルチ・プロセッシング・システムでも必要とされる。
多くのデータ処理システムまたは環境で、データ項目はシステム内の異なるロケーションの間で転送される。これらのロケーションはデータ処理システムのプロセッサ、記憶装置、メモリ、その他である。たとえば、ひとつのプロセッサが別のプロセッサからまたは外部記憶装置から、たとえばフロッピー・ディスクからデータ項目を取得し、（そのデータ項目に提供された名前を用いて）そのデータ項目をシステムに組み込むこともできる。
しかし、プロセッサ（または何らかのロケーション）がＤＰシステムの別のロケーションからデータ項目を取得する場合、この取得したデータ項目がすでにシステム内に（そのプロセッサのロケーションに、またはプロセッサがアクセス可能な何らかの別のロケーションに）存在し、そのためデータ項目の複製が作成されることが考えられる。この状況は所有権を主張できるソフトウェア製品（proprietary software products）がフロッピー・ディスクから共通のファイルサーバを共用する数個のプロセッサへインストールされるネットワーク・データ処理環境で共通している。これらのシステムでは、同一の製品が幾つかのシステムに導入されることが多く、各ファイルの数個のコピーが共通のファイルサーバに残されることになる。
数個のプロセッサがネットワークで接続されているある種のデータ処理システムにおいて、ひとつのシステムがキャッシュ・サーバとして指定されデータ項目のマスター・コピーを保持し、他のシステムはキャッシュ・クライアントに指定されてマスター・データ項目のローカル・コピーを必要に応じてローカル・キャッシュにコピーする。キャッシュした項目を使用する前に、キャッシュ・クライアントはキャッシュした項目を再ロードするか、キャッシュした項目に変更を通知するか、またはキャッシュした項目に対応するマスター項目が変更されなかったことを確認する必要がある。言い換えれば、キャッシュ・クライアントはこれのデータ項目をキャッシュ・サーバ上の項目と同期させる必要がある。この同期はキャッシュ・クライアントへのデータ項目の再ロードを含む。キャッシュを同期させるかまたは再ロードする必要性は既存のキャッシュ機構に顕著なオーバヘッドを付加する。
従来技術のシステムにおける上記およびその他の問題に鑑みて、データ項目のデータだけを使用して何らかの種類のコンテクストに依存することなく、マルチプロセッサ・システムの各プロセッサがデータ項目について共通かつ実質的にユニークな識別子を決定できるようなメカニズムを有するのが所望である。
データ処理システムでデータ項目の複数コピーを減少するメカニズムを有し、また複数コピーを減少するように同一データ項目の識別が行なえるメカニズムを有するのがさらに所望である。あるデータ項目の２つのインスタンスが実際に同一のデータ項目かどうかを判定し、その他の各種システムの機能およびアプリケーションをデータ項目について実行し、データ項目の何らかのコンテクスト情報または属性に依存しないことがさらに所望である。
データ処理システムのユーザには見えないような方法でこのようなメカニズムを提供することも所望であり、また単一のメカニズムを使用して前述の問題の各々に対処できることが所望である。
発明の要約
本発明は、データ処理システムにおいて、システム内のデータ項目を識別する方法および装置を提供するものであり、データ項目の識別はデータ項目内のデータの全部に依存し、かつデータ項目内のデータにしか依存しない。したがってデータ項目の識別は、データから直接導き出せないその名前、起源、ロケーションアドレスまたはその他の情報などから独立しており、またデータ自体にのみ依存する。
本発明はさらに特定のデータ項目がシステム内に、またはシステム内のあるロケーションに存在するかどうか、複数のデータ項目のデータの識別（identity）だけを調べることで判定するための装置および方法を提供する。
本発明の方法または装置を用いると、データ処理システムの効率および完全性（integrity）を改善できる。本発明は、以下の特徴の少なくとも幾つかまたは全部の設計とオペレーションを可能にするか改善することにより、複数のデータ項目を格納するデータ記憶システム、ファイル・システム、リレーショナル・データベース、オブジェクト指向データベースその他の設計およびオペレーションを改善する：
システム内の多数のデータ名が同一内容を参照する場合でも、システムは任意のロケーションに何らかのデータ項目の多くともひとつのコピーを格納する。
宛先ロケーションがすでにデータを有する場合にソースから宛先ロケーションへのデータのコピーを回避する。
現ロケーションがローカルか、リモートか、またはオフラインかとは無関係に、データの識別だけを参照することであらゆるデータ項目へ透過的なアクセスを提供する。
システムはサーバからデータ項目をキャッシュし、最新にアクセスしたデータ項目だけを保持するようにする。
データ項目のキャッシュにシステムが使用されている場合、キャッシュの一貫性を維持する問題を回避する。
システムはサーバのネットワークにおいて所望レベルのデータ項目の冗長性を維持し、データ項目の多数コピーがシステムの異なるロケーションに存在することを保証することにより障害（failure）に対する保護を行なう。
システムはデータ項目が作成されるかまたは変更されると自動的にアーカイブする。
システムはデータ項目がローカル・ファイル・システムから安全に削除できるかどうかを決定するため、データ項目のグループのサイズ、古さ（age）、ロケーションを提供する。
システムはデータ項目のあらゆる集合を効率的に記録し保持することができる。
システムはあらゆるデータ項目の集合のコピーを効率的に作成してデータ項目のグループに対しバージョン制御メカニズムをサポートすることができる。
システムはデータ項目をパブリッシュ（publish）し、その他の、おそらくは匿名（anonymous）の、ネットワーク内のシステムがデータ項目にアクセスしてデータ項目の利用可能性に依存できるようにする。
システムは任意の取り外し可能な媒体、例えばディスケットまたはＣＤ−ＲＯＭ上に位置する全てのデータ項目のローカルなインベントリ（inventory）を維持でき、インベントリはデータ項目の名前、ロケーション、作成日付などの他の属性とは独立である。
システムはデータ項目の密接に関連する集合、たとえば切断されているコンピュータ上の一致または対応するディレクトリ等が定期的に相互に再同期されるようにする。
システムはデータを取り出すために使用されたデータ識別子だけを使用して別のロケーションから取り出したデータが所望のまたは要求されたデータかを確認できる。
システムはデータ項目の内容を開示することなく、後の法的な認証（verification）のためと匿名性（anonymity）を提供するため、内容により特定のデータ項目の所有関係を証明できる。
システムはデータ項目の名前、日付、またはその他の属性とは無関係に、所有者により内容にしたがって特定のデータ項目の所有関係を追跡し、アカウントの目的で内容により特定のデータ項目およびファイルの使用を追跡する。
本発明のその他の目的、特徴、特性ならびに関連する構造の要素のオペレーションと機能の方法、および部材の組合せと製造の経済性については、以下の説明と添付の請求の範囲を勘案し、全部が本明細書の一部を構成している添付の図面を参照することで一層明らかになる。
【図面の簡単な説明】
図１は、本発明の好適実施の形態が動作する代表的なデータ処理システムを示す。
図２は、当該データ処理システムにおいて何らかのロケーションに格納されたデータ項目の階層を示す。
図３から図９は、本発明の実施の形態を実装するために使用されるデータ構造を示す。
図１０（ａ）から図２８は、本発明の各種態様のオペレーションを示すフローチャートである。
現在好適な代表的実施の形態の詳細な説明
典型的なデータ処理システム１００を参照して本発明の実施の形態を説明する。システム１００は、図１を参照すると１つまたは２つ以上のプロセッサ（またはコンピュータ）１０２と何らかの方法、たとえばバス１０６によって接続された各種記憶装置１０４を含む。
各プロセッサ１０２はＣＰＵ１０８、メモリ１１０、および１つまたは２つ以上のローカル記憶装置１１２を含む。ＣＰＵ１０８、メモリ１１０、およびローカル記憶装置１１２はたとえばバス１１４によって内部接続できる。各プロセッサ１０２は他の装置（図示していない）たとえばキーボード、ディスプレイ、プリンタその他も含むことができる。
１つ以上のプロセッサ１０２を使用するデータ処理システム１００において、即ちマルチプロセッサ・システムでは、プロセッサは各種関係のうちのひとつにある。たとえば、２個のプロセッサ１０２はクライアント対サーバ、クライアント対クライアント、またはサーバ対サーバの関係に置かれることがある。これらのプロセッサ間の関連性は動的で、特定の状況および機能にしたがって変化する。したがって特定のプロセッサ１０２は必要に応じて他のプロセッサに対する関係を変化させることがあり、基本的に他のプロセッサとピア・ツー・ピア（peer-to-peer）の関係を設定する。ピア・ツー・ピアの関係において、時には特定のプロセッサ１０２がクライアント・プロセッサとして作用し、他の場合には同じプロセッサがサーバ・プロセッサとして機能する。言い換えれば、プロセッサ１０２に固定されたまたは要求される階層は存在しない。
マルチプロセッサ・システムでは、プロセッサ１０２は同種（homogeneous）または異種（heterogeneous）である。さらに、マルチプロセッサ・データ処理システム１００では、プロセッサ１０２の幾つかまたは全部がある時間間隔に渡ってプロセッサのネットワークから切断されることがある。このような切断はデータ処理システム１００の正常オペレーションの一部か、または特定のプロセッサ１０２に修理が必要なことがある。
データ処理システム１００内部で、データはデータ記憶要素の階層を形成するように構成され低いレベルのデータ記憶要素が組み合されて高いレベルの要素を形成する。この階層は、たとえば、プロセッサ、ファイル・システム、領域、ディレクトリ、データ・ファイル、セグメント、その他から構成することができる。たとえば、図２を参照すると、特定のプロセッサ１０２のデータ項目は領域１１７を含むファイル・システム１１６として構成または構造化され、領域の各々がディレクトリ１１８を含み、ディレクトリの各々が別のディレクトリ１１８またはファイル１２０を含むことができる。各ファイル１２０は１つまたは２つ以上のデータ・セグメント１２２からなる。
典型的なデータ処理システムでは、これらの要素の幾つかまたは全部がユーザによる特定の命名規則の実施により命名でき、要素の名前（またはパス名）はコンテクストに相対的である。データ処理システム１００のコンテクストにおいて、パス名はプロセッサ名、ファイル・システム名、ネストしたディレクトリを識別するゼロまたはひとつ以上のディレクトリ名のシーケンス、および最終的なファイル名で完全に指定される。（通常はもっとも低いレベルの要素、この場合ではデータ・セグメント１２２をユーザが命名できない）。
言い換えれば、ファイル・システム１１６はディレクトリ１１８の集合である。ディレクトリ１１８は名前を付けたファイル１２０−−データ・ファイル１２０と他のディレクトリ・ファイル１１８の両方−−の集合である。ファイル１２０はデータ・ファイル（単純または複合の場合がある）またはディレクトリ・ファイル１１８のどちらかである名前を付けたデータ項目である。単純ファイル１２０は単一のデータ・セグメント１２２から構成される。複合ファイル１２０はデータ・セグメント１２２のシーケンスから構成される。データ・セグメント１２２は一定のバイト・シーケンスである。あらゆるデータ・セグメントの重要な属性はこれの大きさで、シーケンス内のバイト数である。
単一のプロセッサ１０２は１つまたは２つ以上のファイル・システム１１６にアクセスでき、単一の記憶装置１０４は１つまたは２つ以上のファイル・システム１１６またはファイル・システム１１６の一部を含むことがある。たとえば、ファイル・システム１１６は幾つかの記憶装置１０４にまたがることがある。
ファイル・システム内の制御を実装するためには、ファイル・システム１１６を独立した領域に分割し、各領域を管理および制御の単位とする。領域は任意のディレクトリ１１８で構成されディレクトリのパス名（ユーザが定義する）によって識別される。
以下の説明において、データ処理システム１００に関しての術語「ロケーション（location）」は、システム内の特定のプロセッサ１０２，特定のプロセッサのメモリ、記憶装置、取り外し可能な記憶媒体（フロッピー・ディスクまたはコンパクト・ディスク）のいずれか、またはシステム内の何らかの他の物理的ロケーションを表わす。特定のプロセッサ１０２に関する術語「ローカル（local）」はその特定のプロセッサのメモリおよび記憶装置を表わす。
以下の説明において術語「実名（True Name）」、「データ識別（data identity）」、および「データ識別子（data identifier）」は特定のデータ項目について実質的にユニークなデータ識別子を表わす。術語「実ファイル（True File）」は実際のファイル、セグメント、または実名によって識別されたデータ項目を表わす。
データ処理システム１００のファイル・システムについて、オペレーティングシステムのファイル管理システム符号の幾つかを増加することで既存のオペレーティングシステムで動作するように意図して説明する。提供される実施の形態は実際にディスクへデータ項目を保存するためとここから取り出すための標準ファイル管理プリミティブに関連するが、本発明のメカニズムを使用してこれらのデータ項目を参照しアクセスする。
本実施の形態で提供されるプロセスおよびメカニズム（サービス）は以下のカテゴリーにグループ化される：プリミティブ・メカニズム、オペレーティング・システム・メカニズム、リモート・メカニズム、バックグラウンド・メカニズム、拡張メカニズム。
プリミティブ・メカニズムは他のメカニズムをサポートするために用いられる基本的能力を提供する。以下のプリミティブ・メカニズムを説明する：
１．実名を計算する。
２．データ項目をアシミレート（assimilate）する。
３．新規実ファイルを作成する。
４．パスから実名を得る。
５．パスを実名にリンクする。
６．ロケーションから実ファイルを実体化する。
７．リモート・ファイルに位置づける。
８．実ファイルをローカルにする。
９．スクラッチ・ファイルを作成する。
１０．ディレクトリを凍結する。
１１．凍結ディレクトリを展開する。
１２．実ファイルを消去する。
１３．監査ファイル（audit file）エントリを処理する。
１４．グルーミング（grooming）を開始する。
１５．削除のため選択する。
１６．グルーミングを終了する。
オペレーティング・システム・メカニズムは典型的な馴染みのデータ識別子イル・システム・メカニズムを提供し、同時に本発明のメカニズムを提供するために必要とされるデータ構造を保持する。オペレーティング・システム・メカニズムは既存のオペレーティング・システムを拡張するように設計されており、この方法で既存のアプリケーションに対し本発明を互換とし、また一般に透過的にする。以下のオペレーティング・システム・メカニズムを説明する：
１．ファイルを開く。
２．ファイルを閉じる。
３．ファイルを読む。
４．ファイルに書き込む。
５．ファイルまたはディレクトリを消去する。
６．ファイルまたはディレクトリをコピーする。
７．ファイルまたはディレクトリを移動する。
８．ファイル状態を得る。
９．ディレクトリ内のファイルを得る。
リモート・メカニズムはオペレーティング・システムが他のプロセッサからの要求に応答して使用する。これらのメカニズムによって本発明の機能がピア・ツー・ピアのネットワークオペレーションモードで可能になる。以下のリモート・メカニズムを説明する：
１．実ファイルに位置づける。
２．実ファイルを予約する。
３．実ファイルを要求する。
４．実ファイルをリタイア（retire）させる。
５．予約をキャンセルする。
６．実ファイルを取得する。
７．キャッシュをロックする。
８．キャッシュを更新する。
９．有効期限日付をチェックする。
バックグラウンド・メカニズムは低い優先順位でたまに実行することを意図している。これらは本発明に関して自動管理機能を提供する。以下のバックグラウンド・メカニズムを説明する：
１．実ファイルをミラー（mirror）する。
２．領域をグルーミングする。
３．有効期限の切れたリンクをチェックする。
４．領域を検証する。
５．ソース・リストをグルーミングする。
拡張メカニズムはオペレーティング・システム上のアプリケーション・プログラム内で実行する。これらのメカニズムは特定の問題に対する解決と応用を提供する。以下の拡張メカニズムを説明する：
１．既存のディレクトリのインベントリを作成する。
２．取り外し可能な読取り専用ファイルのインベントリを作成する。
３．ディレクトリの同期をとる。
４．領域をパブリッシュ（publish）する。
５．ディレクトリをリタイアする。
６．ディレクトリをロケーションで実体化する。
７．実ファイルを検証する。
８．アカウント目的で追跡する。
９．ライセンス目的で追跡する。
本明細書で説明するファイル・システムは、オペレーティング・システムが通常では提供しないような幾つかを列挙し説明する各種のメカニズムを提供するのに十分な情報を保持する。本発明のこの実施の形態で実行される各種処理についてさらに詳細に説明する。
幾つかの実施の形態において、データ処理システム１００内の幾つかのファイル１２０は最近受信したまたは作成したまたは変更したため、実名は未だ計算されていないので、実名を有していない。まだ実名のないファイルはスクラッチ・ファイル（scratch file）と呼ばれる。実名をファイルに割り当てる処理はアシミレーション（assimilation）と呼ばれ、これについては後述する。スクラッチ・ファイルはユーザが提供した名前を有することに留意されたい。
本発明で実行される処理の幾つかはバックグラウンド・モードでまたは遅延してまたは必要に応じて実行することができる。このバックグラウンド処理はシステムがすぐには必要としない、またはこれまでに要求されたことがない情報を判定するのに使用する。一例として、場合によってはスクラッチ・ファイルが実名を決定するのに有用であるレートより早いレートで変更されている。このような場合、ファイルの実名の決定は後回しにするかバックグラウンドで実行することができる。
データ構造
１つまたは２つ以上のプロセッサ１０２のメモリ１１０に記憶されている以下のデータ構造は本明細書で説明するメカニズムを実施するために使用する。データ構造はシステム１００の各プロセッサ１０２に対してローカルとするか、またはプロセッサ１０２の幾つかにだけ常駐できる。
説明するデータ構造は、データ処理システム１００の個別のピア・プロセッサ１０２に常駐すると仮定する。しかし、リモートの共用ファイル・サーバに（たとえばローカル・エリア・ネットワークの装置に）配置することで共用することもできる。共用データ構造に対応するためには、共用データベースにアクセスするプロセッサが適当なロック技術を用いて、共用データベースへの変更が互いに干渉しないが適切に一元化（serialize）するように保証する必要がある。これらのロック技術は分散アプリケーションに熟練したプログラマには十分に理解されている。
ある領域が特定のプロセッサ１０２に対してローカルであり別の領域がプロセッサ１０２で共用できるのが望ましい場合がある（領域（region）はファイル・システム管理および制御の単位でありディレクトリのパス名で識別される任意のディレクトリから構成される）。ローカルおよび共用領域の場合、各々のデータ構造のローカル・バージョンと共用バージョンの双方が存在し得る。後述する処理の単純な変更は任意のオペレーションについて適当なデータ構造が選択されることを保証するように行なわれるべきである。
ローカル・ディレクトリ拡張（local directory extenions：ＬＤＥ）テーブル１２４はデータ処理システム１００のファイル１２０とディレクトリ１１８に関する情報を提供するデータ構造である。ローカル・ディレクトリ拡張テーブル１２４は、ファイルのパス名またはコンテクスト名（したがってユーザが付与した名前）でインデックスされ多くのファイルで実名を含む。ローカル・ディレクトリ拡張テーブル１２４の情報はオペレーティング・システムの本来のファイル・システムで提供されるそれに追加される。
実ファイル・レジストリ（True File registory：ＴＦＲ）１２６は、ファイル１２０とセグメント１２２両方の、実名を有する実際のデータ項目をリストするためのデータ・ストアである。このようなデータ項目が実ファイル・レジストリ・テーブル１２６に発生した場合、実ファイルとして認識される。実ファイルは実ファイル・レジストリ１２６ではその実名または識別によって識別される。テーブル実ファイル・レジストリ１２６も実ファイルに関するロケーション、依存関係、およびマイグレーション（migration）情報を格納する。
領域テーブル（region table：ＲＴ）１２８は、別個に管理されるべきネットワーク・ストレージにおける領域を定義する。領域テーブル１２８はファイル・システム１１６とリモート・ピア・ファイル・システムを含む種々の領域間でのファイル１２０へのアクセスおよびマイグレーションについての規則を定義する。
ソース・テーブル（source table：ＳＴ）１３０は現在の実ファイル・レジストリ１２６以外の実ファイルのソースについてのリストである。ソース・テーブル１３０は取り外し可能なボリュームやリモート・プロセッサを含む。
監査ファイル（audit file：ＡＦ）１３２は、ローカルまたはリモート・ファイルに行なう変更を表わすレコードのリストで、これらの変更はバックグラウンドで処理される。
アカウント・ログ（accounting log：ＡＬ）１３４は、名前またはロケーションとは独立して追跡しようとするファイルの識別を保存するような方法でアカウント情報を作成するために用いられるファイル・トランザクションのログである。
ライセンス・テーブル（license table：ＬＴ）１３６は、名前またはロケーションおよび使用をライセンスされたユーザとは独立した方法で、ライセンスされたユーザだけが使用するファイルを識別するテーブルである。
データ構造の詳細な説明
次の表は図３のレコード１３８に図示してあるような、ローカル・ディレクトリ拡張テーブル・エントリのフィールドの要約である。
0003865775.tif 000002
0003865775.tif 000003
実ファイル・レジストリ１２６の各レコードは図４の実ファイル・レジストリ・レコード１４０に示したフィールドを備えている。実ファイル・レジストリ１２６は下記の表で説明したデータベースならびに、以下の実ファイルＩＤで識別される実際の実ファイルから構成される。
0003865775.tif 000004
ディレクトリのパス名で指定された領域テーブル１２８はファイル・システム内のファイルを格納し、アクセスし、異なる方法でマイグレート（migrate）できるストレージ・ポリシを記録している。ストレージ・ポリシは設定可能な方法で、後述する規則の集合を用いてプログラムされる。
領域テーブル１２８の各領域テーブル・レコード１４２は以下の表で説明するフィールドを含んでいる（図５を参照）：
0003865775.tif 000005
0003865775.tif 000006
ソース・テーブル１３０は実ファイルのソース・ロケーションを識別する。ソース・テーブル１３０は現在のプロセッサに予約しているクライアント・プロセッサを識別するためにも使用する。ソース・テーブル１３０の各ソース・レコード１４４は図６を参照して以下の表に要約したフィールドを含む：
0003865775.tif 000007
監査ファイル１３２はタイムスタンプの順に並べたイベントのテーブルで、監査ファイル１３２の各レコード１４６は次の表（図７参照）に要約してあるフィールドを含む：
0003865775.tif 000008
アカウント・ログ１３４の各レコード１４８は課金メカニズムに情報を提供するために後で使用するイベントを記録する。各アカウント・ログのエントリ・レコード１４８は少なくとも図８を参照して以下の表に要約した情報を含む：
0003865775.tif 000009
ライセンス・テーブル１３６の各レコード１５０はライセンス可能なデータ項目とこれに自由にアクセスするようにライセンスされたユーザの間の関係を記録する。各ライセンス・テーブル・レコード１５０は図９を参照して以下の表に要約した情報を含む：
0003865775.tif 000010
他の各種データ構造はデータ処理システム１００のプロセッサ１０２の幾つかまたは全部で使用される。各プロセッサ１０２はディレクトリを凍結した時またはコピーする時に同期エラーを防止するために使用するグローバル・フリーズ・ロック（global freeze lock：ＧＦＬ）１５２（図１）を有する。どのプロセッサ１０２もアーカイブの目的でディレクトリをコピーするためのスペシャル・アーカイブ・ディレクトリ（special archive directory：ＳＡＤ）１５４を含むことができる。どのプロセッサ１０２も取り外し可能なボリュームのディレクトリを格納してメディア・インベントリを形成するためのスペシャル・メディア・ディレクトリ（special media directory：ＳＭＤ）１５６を含むことができる。各プロセッサはグルーミング演算の間にセットされるグルーミング・ロック１５８を有する。この期間の間に、実名レジストリ・エントリ１４０のグルーミング消去カウントが有効になり、グルーミングが完了するまで実ファイルは消去されてはならない。グルーミングが有効な間、グルーミング情報は消去のために選択したパス名のテーブルを含み、ファイルを全部消去した場合に使えるようになる空き容量を追跡し続ける。
プリミティブ・メカニズム
本発明で提供されるメカニズムの第１はプリミティブ・メカニズムで、これについて説明する。ここで説明するメカニズムは基盤となるデータ管理メカニズムに依存して、実ファイルＩＤによって識別される実ファイル・レジストリ１２６のデータ項目を作成、コピー、読み出し、消去する。このサポートは基盤となるオペレーティング・システムまたはディスク・ストレージ・マネージャによって提供できる。
以下のプリミティブ・メカニズムについて説明する：
１．実名を計算する。
２．データ項目をアシミレートする。
３．新規実ファイルを作成する。
４．パスから実名を得る。
５．パスを実名にリンクする。
６．ロケーションから実ファイルを実体化する。
７．リモート・ファイルに位置づける。
８．実ファイルをローカルにする。
９．スクラッチ・ファイルを作成する。
１０．ディレクトリを凍結する。
１１．凍結ディレクトリを展開する。
１２．実ファイルを消去する。
１３．監査ファイル・エントリを処理する。
１４．グルーミングを開始する。
１５．削除のため選択する。
１６．グルーミングを終了する。
１．実名を計算する
実名は、任意の長さのデータブロックＢを比較的小さな一定サイズの識別子であるそのデータブロックの実名に縮小する関数ＭＤを用いて計算し、データブロックの実名がデータブロックＢを表わしかつデータブロックＢしか表わさないように事実上保証するようにする。
関数ＭＤは次の属性を有している必要がある。
１．関数ＭＤのドメインは全データ項目の集合である。関数ＭＤの範囲は実名の集合である。
２．関数ＭＤは任意の長さのデータ項目を取り、Ｎを実名の集合の濃度（cardinality）とすると、項目を０からＮ−１までの範囲の整数値に縮小しなければならない。したがって、任意の長さのデータブロックＢについて、０≦ＭＤ（Ｂ）＜Ｎとする。
３．ＭＤ（Ｂ）の結果は、単純なまたは一定のＢへの変更が異なるＭＤ（Ｂ）の値を発生することを事実上保証するような方法で、Ｎの範囲に渡って均等かつランダムに分散する必要がある。
４．ＭＤ（Ｂ）＝ＭＤ（Ｂ′）となるような異なる値Ｂ′を見付けることが計算上困難でなければならない。
５．関数ＭＤ（Ｂ）は効率的に計算できなければならない。
以上の性質を備える関数族（family of functions）はいわゆるメッセージ・ダイジェスト関数（message digest functions）で、これはデータ認証のための技術としてディジタル保安システムで使用される。これらの関数（またはアルゴリズム）はＭＤ４、ＭＤ５、ＳＨＡを含む。
現在好適な実施の形態において、ＭＤ５またはＳＨＡは実名の計算の基本に使用される。これら２つのメッセージ・ダイジェスト関数のどちらを用いるとしても、同じ関数をシステム全体で使用する必要がある。
関数の範囲のエレメント数がドメインのエレメント数より小さい場合に、考えられる各入力についてユニークな出力を有する関数を定義するのは不可能である。しかし、重要なことは、本発明を実施する何らかのシステムの運用で遭遇することになる実際のデータ項目が考えられる入力の全部のうちで非常に疎な部分集合を形成するという点である。
データ項目の衝突集合（colliding set）は、その集合の１つまたは２つ以上のｘとｙの対について、ＭＤ（Ｘ）＝ＭＤ（ｙ）となるような集合として定義される。ＭＤの要件に適合する関数は出力を均等かつランダムに分散しなければならないことから、関数の範囲を十分に大きく取ることによって、本発明の実施の形態の運用で遭遇する実際の入力が衝突集合を形成する確率を任意に小さくすることが可能である。
衝突の可能性を大まかに定量するには、２３０個以上の記憶装置が世界中に存在しないなら、また各記憶装置が平均して多くとも２２０個の異なるデータ項目を有すると仮定する。したがって世界中には多くとも２５０のデータ項目が存在する。ＭＤの出力範囲が０から２１２８の間にあれば、衝突の可能性は２２９分の１程度であると示すことができる。これらの確率値の誘導の詳細は、たとえばP. Flajolet and A.M. Odlyzko,「ランダム・マッピング統計学（Random Mapping Statistics）」、Lecture Notes in Computer Science 434:Advances in Cryptology -- Eurocrypt '89 Proceedings, Springer-Verlag, pp. 329-354に記載されている。
本発明のもっと少ない好適実施の形態では、用途および使用するメカニズムの種類によって、ユニーク度のもっと低い確率が受け入れ可能であることに留意されたい。幾つかの実施の形態においては、実名のひとつ以上のレベルを有し、実名の幾つかは度合の異なるユニーク度を有するのも有用であろう。このような方式が実装される場合、ユニーク度の小さい実名がシステムに伝播しないことを保証する必要がある。
本発明はデータ項目の識別子としてデータ項目の実名だけを使用するように説明しているが、他の好適実施の形態ではタグ付け、型付け、カテゴリー分け、または分類したデータ項目を使用し、実名とデータ項目のこれらのタグ、型、カテゴリー、またはクラスの両方の組み合せを識別子として使用する。このような分類の例は、ファイルとディレクトリとセグメント、実行可能ファイルとデータ・ファイル、その他である。クラスの例はオブジェクト指向システムにおけるオブジェクトのクラスがある。このようなシステムでは、データ項目のカテゴリーごとに十分なユニーク度が提供される限り、実名のユニーク度の度合が低い方が、データ項目の全範囲に渡って受け入れられる。これは、ユニーク度の追加のレベルをタグが提供するためである。
データ項目を与えられた実名計算メカニズムについて、図１０（ａ）および図１０（ｂ）を参照して説明する。
単純なデータ項目はサイズが特定の任意のサイズより小さい（本発明の特定の実装の各々で定義する必要がある）ようなデータ項目である。単純なデータ項目の実名を決定するには、図１０（ａ）を参照すると、第１に与えられた単純なデータ項目についてＭＤ関数（前述）を計算する（ステップＳ２１２）。次に、得られた１２８ビットに、データ項目のバイト長のモジュロ３２を加える（ステップＳ２１４）。得られた１６０ビットの値が簡単なデータ項目の実名となる。
複合（compound）データ項目は、単純なデータ項目の特定の任意のサイズよりサイズが大きなデータ項目である。任意の（単純または複合）データ項目の実名を決定するには、図１０（ｂ）を参照すると、第１にデータ項目が単純または複合データ項目なのかを判定する（ステップＳ２１６）。データ項目が単純データ項目であれば、ステップＳ２１８で（前述のステップＳ２１２およびＳ２１４を用いて）実名を計算し、それ以外の場合にはデータ項目をセグメントに分割して（ステップＳ２２０）から、各セグメントをアシミレートし（ステップＳ２２２）（プリミティブ・メカニズムであるデータ項目のアシミレーションは後述する）、セグメントの実名を計算する。次に計算したセグメントの実名から構成される間接ブロックを作成する（ステップＳ２２４）。間接ブロックはセグメントの実名のシーケンスから構成されるデータ項目である。次に、ステップＳ２２６で、間接ブロックをアシミレートし、これの実名を計算する。最後に、得られた実名の最後の３２ビット（したがって間接ブロックの長さ）を複合データ項目の長さのモジュロ３２で置き換える（ステップＳ２２８）。結果が複合データ項目の実名となる。
複合データ項目は非常に大きくて実名セグメントの間接ブロックそれ自体が複合データ項目となることがあることに留意されたい。この場合、単純データ項目だけが処理されるようになるまで再帰的にメカニズムを起動する。
セグメントの使用、および実名に長さを追加することの両方は本発明を使用するシステムで厳密には要求されるものではないが、好適実施の形態で現在のところ望ましい特徴であると考えられる。
２．データ項目のアシミレーション
データ項目のスクラッチ・ファイルＩＤが与えられるとデータ項目（スクラッチ・ファイルまたはセグメント）をファイル・システムにアシミレートするメカニズムについて、図１１を参照して説明する。このメカニズムの目的は実ファイル・レジストリ１２６に任意のデータ項目を追加することである。データ項目が実ファイル・レジストリ１２６にすでに存在する場合、これを見つけ出してこの処理の間に使用し、複製を除去する。
これによってシステムは多数の名前で同一内容を参照している時でも、内容により何らかのデータ項目またはファイルの多くともひとつのコピーを格納する。
第１に、実名計算プリミティブ・メカニズム（ステップＳ２３０）を使用して与えられたスクラッチ・ファイルＩＤに対応するデータ項目の実名を決定する。次に、実ファイル・レジストリ１２６で実名のエントリを検索し（ステップＳ２３２）、実名エントリ、レコード１４０が実ファイル・レジストリ１２６に存在するかどうかを決定する。エントリ・レコードが対応する実ファイルＩＤまたは圧縮ファイルＩＤを含む場合（ステップＳ２３７）、スクラッチ・ファイルＩＤをもつファイルを消去する（ステップＳ２３８）。それ以外の場合にはエントリ・レコードに与えられた実ファイルＩＤを格納する（ステップＳ２３９）。
実ファイル・レジストリ１２６に実名エントリが存在しないと判定した場合（ステップＳ２３２で）、ステップＳ２３６においてこの実名に対する実ファイル・レジストリの新規エントリを作成する。エントリの実名を、計算した実名にセットし、新規エントリの使用カウントを１にセットし、エントリに与えられた実ファイルＩＤを格納して、エントリの他のフィールドを適切にセットする。
この手順は計算にいくらか時間がかかるため、ファイルの変更が終ってからバックグラウンドで実行するように意図している。それまでの間、ファイルはアシミレートされていないスクラッチ・ファイルと考えられる。
３．新規実ファイル
新規実ファイル処理は、実ファイルがアシミレートされてから（プリミティブ・メカニズムであるデータ項目のアシミレートを使用する）しばらく後で、監査ファイル１３２を処理する時に起動される。ローカル・ディレクトリ拡張テーブル１２４にローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を与えると、新規実ファイル処理はローカル・プロセッサがどのように設定されているかによって、以下のステップを提供できる（図１２参照）：
第１に、ステップＳ２３８で、ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を調べてファイルがキャッシュ・サーバよりロックされているか決定する。ファイルがロックされている場合、キャッシュ・サーバのＩＤを実ファイル・レジストリ１２６の依存プロセッサ・リストに追加してから、キャッシュ・サーバにメッセージを送り、キャッシュ更新リモート・メカニズムを使用して現在のプロセッサのキャッシュを更新する（ステップ２４２）。
所望なら実ファイルを圧縮し（ステップＳ２４６）、また所望ならミラー実ファイル・バックグラウンド・メカニズムを使用して実ファイルをミラーする（ステップＳ２４８）。
４．パスから実名を得る
ファイルの実名は内容でファイルを識別するため、ファイルがもとの内容と一致することを確認するため、または２つのファイルを比較するために使用できる。ファイルのパス名が与えられた実名を取り出すメカニズムについて、図１３を参照して説明する。
第１に、ローカル・ディレクトリ拡張テーブル１２４で与えられたパス名をもつエントリ・レコード１３８を検索する（ステップＳ２５０）。パス名が見つからない場合、この処理が失敗し、与えられたパス名に対応する実名は存在しない。次に、ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８が実名を含むか決定し（ステップＳ２５２）、含む場合には、メカニズムのタスクを完了する。それ以外の場合、ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８がディレクトリを識別するか決定する（ステップＳ２５４）。ディレクトリであれば、そのディレクトリを凍結する（ステップＳ２５６）（プリミティブ・メカニズムのディレクトリの凍結は後述する）。
それ以外の場合、ステップＳ２５８で、ファイルＩＤフィールドで定義されたファイルをアシミレートし（プリミティブ・メカニズムのデータ項目のアシミレートを使用する）、これの実名を生成して、ローカル・ディレクトリ拡張テーブル・エントリ・レコードに実名を格納する。次に、ローカル・ディレクトリ拡張テーブル１２４で識別される実名を返す。
５．パスを実名にリンクする
パスを実名にリンクするメカニズムは、既存のアシミレートしたファイルを識別する新規ディレクトリ・エントリ・レコードを作成する方法を提供する。この基本プロセスは、内容をコピーすることなく、ファイルをコピーし、移動し、リネームするために使用できる。パスを実名にリンクするメカニズムについて、図１４を参照して説明する。
第１に、所望なら、実名レジストリまたはローカル・ディレクトリ拡張テーブル１３５を検索することで実名がローカルに存在することを確認する（ステップＳ２６０）。このメカニズムの用途の多くでは、この形態の確認が必要であろう。次に、ローカル・ディレクトリ拡張テーブル１３５でパスを検索する（ステップＳ２６２）。パスで名付けられたファイルを含むディレクトリがすでに存在することを確認する（ステップＳ２６４）。名付けられたファイルそれ自体が存在する場合には、実ファイル消去オペレーティング・システム・メカニズム（後述）を用いてファイルを消去する（ステップＳ２６８）。
次に、指定されたパスでローカル・ディレクトリ拡張にエントリ・レコードを作成する（ステップＳ２７０）。また次のようにエントリ・レコードならびにその他のデータ構造を更新する：エントリの実名フィールドには指定された実名を書き込む。対応する実名の実ファイル・レジストリ・レコード１４０で使用カウントをインクリメントする。実ファイルを読み込んで、これが凍結ディレクトリを表わしていることを示すタグ（マジック・ナンバー）を含むか調べることでエントリがディレクトリかどうかを調べる（タグに関するディレクトリの凍結プリミティブ・メカニズムの説明も参照のこと）。ローカル・ディレクトリ拡張の他のフィールドを計算し適切にセットする。たとえば、領域テーブル１２８を調べてパスの領域を識別し、最新アクセスの時刻と最新変更の時刻を現在時刻にセットする。
６．ロケーションから実ファイルを実体化する
このメカニズムは、実名と実ファイルを含むソース・ロケーション（プロセッサまたは媒体）の名前とが与えられた実ファイルのローカル・コピーを作成しようと試みるために使用する。このメカニズムは図１５を参照して説明する。
第１に、ステップＳ２７２において、指定されたロケーションがプロセッサかどうかを決定する。指定されたロケーションがプロセッサであると決定された場合、実ファイル要求のメッセージ（実ファイル要求リモート・メカニズムを使用する）をリモート・プロセッサに送信して応答を待つ（ステップＳ２７４）。否定応答を受信したか、タイムアウト期間の後応答が受信されない場合、このメカニズムは失敗する。肯定的応答が受信されれば、実ファイル・レジストリ１２６に返される実ファイルを入力する（ステップＳ２７６）（受信したファイルが圧縮されている場合には、圧縮ファイルＩＤフィールドに実ファイルＩＤを入力する）。
一方で、指定されたロケーションがプロセッサではない場合、必要であればユーザまたはオペレータに指示されたボリュームをマウントするように要求する（ステップＳ２７８）。次に、（ステップＳ２８０）、与えられたボリューム上の示されたファイルを検索し、データ項目のアシミレート・プリミティブ・メカニズムを用いてファイルをアシミレートする。ボリュームが実ファイル・レジストリ１２６を含まない場合、メディア・インベントリを検索してボリューム上のファイルを検索する。該当するファイルを見付けられない場合、このメカニズムは失敗する。
この時点で、ロケーションがプロセサであると決定されたかどうか（ステップＳ２７２）より、所望であれば実ファイルを検証する（ステップＳ２８２）。
７．リモート・ファイルに位置づける
このメカニズムでは特定のソースが未知か利用できない場合に、プロセッサが実ファイルのリモート・ソースからファイルまたはデータ項目を特定できる。クライアント・プロセッサ・システムは与えられた実名をもつデータ・オブジェクトを供給できるかどうか、幾つかのまたは多くのソースのひとつに問い合わせる。このメカニズムを実行するステップは次の通りである（図１６を参照する）。
クライアント・プロセッサ１０２はソース・テーブル１４５を使用して１つまたは２つ以上のソース・プロセッサを選択する（ステップＳ２８４）。ソース・プロセッサが見付からない場合、メカニズムは失敗する。次にクライアント・プロセッサ１０２は選択したソースに対して、実ファイル検索リモート・メカニズムを使用して与えられた実名をもつファイルを検索するための要求をブロードキャストする（ステップＳ２８６）。検索要求は離れたサーバへこの要求を伝播するように問い合わせることにより増大することがある。クライアント・プロセッサは１つまたは２つ以上のサーバが肯定的に応答するのを待つ（ステップＳ２８８）。全てのサーバが否定応答した後、または肯定応答なしにタイムアウト期間が経過した後、メカニズムは選択を繰り返して（ステップＳ２８４）、別のソースを識別しようと試みる。いずれかの選択されたソース・プロセッサが応答した場合、これのプロセッサＩＤがこのメカニズムの結果となる。与えられた実名の実ファイル・レジストリ・エントリ・レコード１４０のソース・フィールドにプロセッサＩＤを格納する（ステップＳ２９０）。
実名のソース・ロケーションが宛先とは別のプロセッサまたは媒体の場合（ステップＳ２９０ａ）、次のステップを実行する：
（i）対応する実名について実ファイル・レジストリ・エントリ・レコード１４０を参照し、ソース・ロケーションＩＤを実名についてのソースのリストに追加する（ステップＳ２９０ｂ）、そして、
（ii）ソースがパブリッシング・システムの場合、その実名についてパブリッシング・システム上の有効期限を調べこれをソースのリストに追加する。ソースがパブリッシング・システムではない場合、メッセージを送信してソース・プロセッサ上で実ファイルを予約する（ステップＳ２９０ｃ）。
ステップＳ２８４でのソース選択はソースの一般的利用可能性、アクセス時刻、バンド幅、転送コストに関係する最適化に基づくことがあり、ステップＳ２８８で応答しなかったそれまでに選択されたプロセッサを無視する。
８．実ファイルをローカルにする
このメカニズムは実名が分かっている場合で対応するファイルまたはデータ項目のローカルにアクセスできるコピーが要求される場合に使用する。このメカニズムでは実ファイルにあるデータを実際に読み込むことが可能になる。このメカニズムは実名を取りローカルにアクセス可能な実ファイルが実ファイル・レジストリ１２６に存在する場合に応答を返す。このメカニズムについて、図１７のフローチャートを参照して説明する。
第１に、実ファイル・レジストリ１２６で対応する実名についての実ファイル・レジストリ・エントリ・レコード１４０を検索する（ステップＳ２９２）。このようなエントリが見つからない場合、このメカニズムは失敗する。そのエントリについて実ファイルＩＤがすでに存在する場合（ステップＳ２９４）、このメカニズムのタスクは完了する。そのエントリに圧縮ファイルＩＤが存在する場合（ステップＳ２９６）、ファイルＩＤに対応するファイルを展開し（ステップＳ２９８）、展開したファイルＩＤをエントリに格納する（ステップＳ３００）。このメカニズムはこれで終了する。
そのエントリで実ファイルＩＤが存在しない場合（ステップＳ２９４）、またそのエントリに圧縮ファイルＩＤが存在しない場合（ステップＳ２９６）、要求されたファイルの検索を続行する。この時点でシステムは要求されたファイルを検索中であるとユーザに通知する必要がある。
１つまたは２つ以上のソースＩＤが存在する場合には、ソースＩＤを実体化しようと試みる順序を選択する（ステップＳ３０４）。順序はソースの一般的利用可能性、アクセス時刻、バンド幅、転送コストに関係する最適化に基づく。選択した順番の各ソースに対して、実ファイルが実体化されるまで（ロケーションから実ファイルを実体化するプリミティブ・メカニズムを使用する）ソース・ロケーションから実ファイルを実体化する（ステップＳ３０６）。実体化されれば、ステップＳ２９４から継続する。分かっているソースが実ファイルを実体化できない場合には、リモート・ファイルの検索プリミティブ・メカニズムを使用して実ファイルを検索しようと試みる（ステップＳ３０８）。これに成功すれば、同定したソース・ロケーションから実ファイルを実体化して、ステップＳ２９６から継続する。
９．スクラッチ・ファイルを作成する
ファイルのスクラッチ・コピーは、ファイルを作成する際、または変更しようとする時に必要になる。スクラッチ・コピーは基本となるオペレーティング・システムのファイル・システムに格納される。スクラッチ・コピーは監査ファイル・レコード・エントリ１４６が監査ファイル・エントリの処理プリミティブ・メカニズムによって処理された時に最終的にアシミレートされる。このスクラッチ・ファイル作成メカニズムはローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を必要とする。これに成功した場合、ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８は実ファイル・レジストリ１２６に含まれておらず変更可能なスクラッチ・ファイルのスクラッチ・ファイルＩＤを含む。このメカニズムについて、図１８を参照して説明する。
第１にスクラッチ・ファイルが既存の実ファイルのコピーであるべきかを決定する（ステップＳ３１０）。そうなら、ステップＳ３１２へ続く。それ以外の場合には、ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８が既存の実ファイルを識別するか決定し（ステップＳ３１６）、そうなら、実ファイル消去プリミティブ・メカニズムを使用して実ファイルを消去する（ステップＳ３１８）。次に新規に空のスクラッチ・ファイルを作成してこれのスクラッチ・ファイルＩＤをローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８に格納する（ステップＳ３２０）。このメカニズムはここで終了する。
ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８がスクラッチ・ファイルＩＤを識別している場合（ステップＳ３１２）、そのエントリはすでにスクラッチ・ファイルを有しているので、このメカニズムは継続される。
ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８が実ファイルを識別している場合（ステップＳ３１６）、実ファイルをローカルに作成するプリミティブ・メカニズムを使用して実ファイルをローカルに作成する（ステップＳ３２２）。さらに実ファイルのＩＤも存在しなければ、このメカニズムは失敗する。
ここで、このファイルについてローカルな実ファイルが存在する。対応する実ファイル・レジストリ・エントリ・レコード１４０の使用カウントが１の場合（ステップＳ３２６）、ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８のスクラッチ・ファイルＩＤに実ファイルＩＤを保存し、実ファイル・レジストリ・エントリ・レコード１４０を削除する（ステップＳ３２８）。（このステップは実ファイルをスクラッチ・ファイルにする）。このメカニズムのタスクはこれで完了する。
それ以外の場合、対応する実ファイル・レジストリ・エントリ・レコード１４０の使用カウントが１ではない場合（ステップＳ３２６で）、ファイル読み込みオＯＳメカニズムを使用して、与えられた実ファイルＩＤをもつファイルを新規スクラッチ・ファイルにコピーし、これのファイルＩＤをローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８に格納し（ステップＳ３３０）、実ファイルの使用カウントを１だけ減少する。コピーを行なうのに不十分な空きスペースしかなければ、このメカニズムは失敗する。
１０．ディレクトリを凍結する
このメカニズムは実名を計算するためにディレクトリを凍結する。ディレクトリの実名はディレクトリ内部のファイルの関数であるため、ディレクトリの実名の計算中は変更されてはならない。このメカニズムは凍結するディレクトリのパス名を必要とする。このメカニズムについて図１９を参照して説明する。
ステップＳ３３２において、グローバル・フリーズ・ロックに１を加える。次にローカル・ディレクトリ拡張テーブル１２４を検索して与えられたディレクトリに従属するデータ・ファイルおよびディレクトリの各々を調べ、見付かった従属ディレクトリの各々はディレクトリ凍結プリミティブ・メカニズムを使用して凍結する（ステップＳ３３４）。ディレクトリ内のアシミレートしていない各データ・ファイルはデータ項目アシミレートのプリミティブ・メカニズムを使用してアシミレートする（ステップＳ３３６）。次に、タグまたはマーカ（「マジック・ナンバー」）ではじまり、このデータ項目が凍結ディレクトリであることを表わすユニークなデータ項目であるようなデータ項目を作成する（ステップＳ３３７）。次に、現在のディレクトリの各ファイルについてファイル名と実名をリストする（ステップＳ３３８）。必要な追加情報たとえば型、最新アクセスおよび変更の時刻、およびサイズ等を全て記録する（ステップＳ３４０）。次に、ステップＳ３４２で、データ項目アシミレートのプリミティブ・メカニズムを使用し、ステップＳ３３８で作成したデータ項目をアシミレートする。得られた実名は凍結ディレクトリの実名である。最後に、グローバル・フリーズ・ロックから１を減算する（ステップＳ３４４）。
１１．凍結ディレクトリを展開する
このメカニズムは任意のロケーションにある凍結ディレクトリを展開する。ディレクトリを展開しようとする任意のパス名と、ディレクトリの実名を必要とし、図２０を参照して説明する。
第１に、ステップＳ３４６で、実ファイルをローカルにするプリミティブ・メカニズムを使用して任意の実名をもつ実ファイルをローカルにする。次に、ステップＳ３４６で作成されたローカル・ファイルにある各ディレクトリ・エントリを読み込む（ステップＳ３４８）。このようなディレクトリ・エントリの各々について、以下を実行する：
エントリの与えられたパス名とファイル名を使用してフル・パス名（full pathname）を作成し（ステップＳ３５０）、
実名にパス名をリンクするプリミティブ・メカニズムを使用して作成したパスをリンクする（ステップＳ３５２）。
１２．実ファイルを消去する
このメカニズムは実名への参照を消去する。基本となる実ファイルは、そのファイルへの追加的な参照が存在しないのでなければ、実ファイル・レジストリ１２６から削除されない。図２１を参照すると、このメカニズムは次のように実行される。
グローバル・フリーズ・ロックがオンになっていれば、グローバル・フリーズ・ロックがオフになるまで待機する（ステップＳ３５４）。これは、このファイルを参照するディレクトリが凍結されている間に実ファイルを削除しないようにするものである。次に、実ファイル・レジストリ・エントリ・レコード１４０で与えられた実名を検索する（ステップＳ３５６）。実ファイル・レジストリ１２６の参照カウント・フィールドがゼロより大きい場合、参照カウント・レコードから１を減算する（ステップＳ３５８）。（ステップＳ３６０で）実ファイル・レジストリ・エントリ・レコード１４０の参照カウント・フィールドがゼロだと決定された場合、また実ファイル・レジストリ・エントリ・レコード１４０に依存システムがリストされていない場合、以下のステップを実行する：
（i）実ファイルが単純データ項目であれば、その実ファイルを消去し、それ以外の場合、
（ii）（実ファイルが複合データ項目である）データ項目の各実名について、実名に対応する実ファイルを再帰的に消去する（ステップＳ３６２）。
（iii）実ファイルＩＤと圧縮ファイルＩＤで表わされるファイルを実ファイル・レジストリ１２６から削除し、実ファイル・レジストリ・エントリ・レコード１４０を削除する（ステップＳ３６４）。
１３．監査ファイル・エントリを処理する
このメカニズムはローカル・ディレクトリ拡張テーブル１２４と実ファイル・レジストリ１２６に情報を保持するのに必要とされるタスクを実行するが、もっとタイム・クリティカルな（time-critical）タスクを実行してプロセッサがビジーな間は遅延させることができる。監査ファイル１３２のエントリ１４２は、処理すべきエントリがある間はバックグラウンドの優先順位で処理すべきである。図２２を参照すると、エントリを処理するステップは次の通りである：
現在処理しているエントリ１４２における演算を決定する（ステップＳ３６５）。ファイルが作成されたか書き込まれたことを演算が表わす場合（ステップＳ３６６）、ＩＤをアシミレートするプリミティブ・メカニズムを使用してファイルをアシミレートする（ステップＳ３６８）。新規実ファイル・プリミティブ・メカニズムを使用してさらに所望の処理を実行し（たとえばキャッシュの更新、圧縮、ミラーリング等）（ステップＳ３６９）、そのファイルについて新規に計算した実名を監査ファイルのレコード・エントリに記録する（ステップＳ３７０）。
それ以外の場合、処理しているエントリが複合データ項目またはディレクトリをコピーした（または消去した）ことを表わしている場合（ステップＳ３７６）、複合データ項目またはディレクトリの各コンポーネントの実名について、コンポーネント実名に対応する実ファイル・レジストリ・エントリ・レコード１４０の使用カウントに１を加える（１を減算する）（ステップＳ３７８）。
全ての場合で、任意のファイルの親ディレクトリの各々について、監査レコードの演算にあわせてサイズ、最新アクセス時刻、最新変更時刻を更新する（ステップＳ３７９）。
監査レコードは処理後に削除されず、何らかの妥当な期間に渡って保持され、ディレクトリの同期の拡張メカニズムによって使用されて、切断されたリモート・プロセッサがローカル・システムの表現を更新できるようにする。
１４．グルーミングを開始する
このメカニズムは削除するファイルの集合を選択して、回復される空き容量の総量を決定できるようにする。図２３を参照すると、第１にグローバル・グルーミグ・ロックが現在ロックされていないことを確認する（ステップＳ３８２）。次に、グローバル・グルーミグ・ロックをセットし、グルーミング中に解放される容量の総量をゼロにセットし、消去するために選択したファイルのリストを空にする（ステップＳ３８４）。実ファイル・レジストリ１２６の実ファイル各々について、消去カウントをゼロにセットする（ステップＳ３８６）。
１５．削除のため選択する
このグルーミング・メカニズムは、一時的にパス名を選択してそれに対応する実ファイルが削除できるようにする。図２４を参照すると、第１に与えられたパス名に対応する領域テーブル１３８を検索する（ステップＳ３８８）。次にローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８の実ファイルの名前に対応する実ファイル・レジストリ・エントリ・レコード１４０を検索する（ステップＳ３９０）。実ファイル・レジストリ・エントリ・レコード１４０のグルーミング消去カウントに１を加える（ステップＳ３９２）。実ファイル・レジストリ・エントリ・レコード１４０のグルーミング消去カウントが、実ファイル・レジストリ・エントリ・レコード１４０の使用カウントに等しい場合、また実ファイル・レジストリ・エントリ・レコード１４０の依存リストにエントリがない場合、実ファイルＩＤおよび、または圧縮ファイルＩＤで示されたファイルのサイズをグルーミング中に解放される空間の総量に加える（ステップＳ３９４）。
１６．グルーミングを終了する
このグルーミング・メカニズムは、グルーミング・フェーズを終了し削除のために選択された全ファイルを削除する。図２５を参照すると、消去するために選択されたファイルのリストにある各ファイルについて、ファイルを消去して（ステップＳ３９６）からグローバル・グルーミング・ロックを解除する（ステップＳ３９８）。
オペレーティング・システム・メカニズム
本発明によって提供される次のメカニズムは、オペレーティング・システム・メカニズムであり、これについて説明する。
次のオペレーティング・システム・メカニズムを説明する：
１．ファイルを開く。
２．ファイルを閉じる。
３．ファイルを読む。
４．ファイルに書き込む。
５．ファイルまたはディレクトリを消去する。
６．ファイルまたはディレクトリをコピーする。
７．ファイルまたはディレクトリを移動する。
８．ファイル状態を得る。
９．ディレクトリ内のファイルを得る。
１．ファイルを開く
ファイルを開くメカニズム（open file mechanism）は図２６を参照して説明する。このメカニズムは入力としてパス名と、そのファイルに必要なアクセスの型（たとえば、読み込み、書き込み、読み／書き、作成、等）を与えられ、開こうとするファイルのファイルＩＤまたはファイルを開くべきでないという指示を作成する。開いたファイルに関係するローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８と領域テーブル・レコード１４２は、そのファイルを参照する他の処理関数たとえば読み込み、書き込み、閉じる等で後に使用するためファイルを開くことに関係する。
第１に、指定されたファイルがローカルに存在するかどうか、ローカル・ディレクトリ拡張テーブル１２４を調べて与えられたパス名に対応するエントリが存在するかどうかを決定する（ステップＳ４００）。ファイル名がローカルに存在しないと決定された場合には、アクセス型を使用して、そのファイルがこの開く処理（opening process）で作成されるかどうかを決定する（ステップＳ４０２）。ファイルが作成されていない場合、ローカル・ディレクトリ拡張テーブル１２４を使用して長さが０のスクラッチ・ファイルを作成し、このスクラッチ・ファイルのスクラッチ・ファイルＩＤを結果として作成する（ステップＳ４０６）。一方、ステップＳ４００で、ファイル名がローカルに存在していると決定した場合、領域テーブル１２８を検索してファイルのパス名のプレフィックスである最も長い領域パスを有するレコード１４２を見つけ出すことにより、ファイルが位置している領域を決定する（ステップＳ４０８）。このレコードは指定されたファイルの領域を識別する。
次に、アクセス型を用いて、書込みのためにファイルが開かれているか、または読み取りのためだけに開かれているかどうかを決定する（ステップＳ４１０）。ファイルが読み取り専用に開かれている場合には、次にファイルがスクラッチ・ファイルなら（ステップＳ４１９）、そのファイルのスクラッチ・ファイルＩＤを返す。それ以外の場合、ローカル・ディレクトリ拡張テーブル１２４から実名を取り出して、実ファイルをローカルにするプリミティブ・メカニズムを用いることにより実名に関連する実ファイルのローカル・バージョンを作成し、実名に関連する実ファイルＩＤを返す（ステップＳ４２０）。
ファイルが読み取り専用に開かれていない場合には（ステップＳ４１０）、ファイルが読取り専用ディレクトリにあると領域テーブル・レコード１４２を調べて決定されれば（ステップＳ４１６）、開くことを禁止する（ステップＳ４２２）。
領域テーブル１２８を調べてファイルがキャッシュ領域にあると分かった場合（ステップＳ４２３）、キャッシュ・ロック・メッセージを対応するキャッシュ・サーバに送信し、リターン・メッセージを待つ（ステップＳ４１８）。リターン・メッセージでファイルがすでにロックされているとなっていれば、開くことを禁止する。
変更しようとするファイルが完全に書き直されつつあるとアクセス型が示している場合（ステップＳ４１９）、もとのデータは要求されないので、ファイル消去オペレーティング・システム・メカニズムを使用してファイル消去を行ない（ステップＳ４２１）、ステップＳ４０６を実行する。それ以外の場合、ファイルのスクラッチ・コピーを作成して（ステップＳ４１７）、結果としてスクラッチ・ファイルのスクラッチ・ファイルＩＤを生成する（ステップＳ４２４）。
２．ファイルを閉じる
このメカニズムは入力として開いたファイルのローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８とその開いたファイルのために保持されるデータを取る。ファイルを閉じるには、時刻とオペレーション（作成、読み込み、または書き込み）を表わす監査ファイルにエントリを追加する。監査ファイルの処理（監査ファイル・エントリの処理プリミティブ・メカニズムを使用する）はファイルのアシミレーションを取り扱うので他のレコードの更新を行なう。
３．ファイルを読み込む
ファイルを読み込むには、プログラムは読み込もうとするデータのオフセットと長さ、および読み込まれたデータをコピーするバッファのロケーションを提供する必要がある。
読み込まれるファイルは上記で定義したオープン・ファイル・オペレーティング・システム・メカニズム（Open File operating system mechanism）で計算されたファイルＩＤを含むオープン・ファイル記述子（open file descriptor）によって識別される。ファイルＩＤはスクラッチ・ファイルまたは実ファイル（または実ファイル・セグメント）どちらかを識別する。ファイルＩＤが実ファイルを識別する場合、ファイルは単純または複合実ファイルのどちらかである。ファイルの読み込みは次のステップで実現される：
ファイルＩＤがスクラッチ・ファイルまたは単純実ファイルを識別する場合には、基本となるオペレーティング・システムの読み込み能力を使用する。
ファイルＩＤが複合ファイルを識別する場合には、読み込みオペレーションを次のようにコンポーネント・セグメントについての１つまたは２つ以上の読み込みオペレーションに分割する：
Ａ．指定されたファイルのオフセットと長さを各々一定サイズのセグメント（システム依存パラメータ）に分割することで読み込もうとするセグメント（または複数のセグメント）を識別し、セグメント番号と読み込む必要のあるセグメント個数を決定する。
Ｂ．上記で計算した各々のセグメント番号について、以下を実行する：
i．複合実ファイル・インデックス・ブロックを読み込んで読み込むセグメントの実名を決定する。
ii．ロケーションから実ファイルを実体化するプリミティブ・メカニズムを使用して、実ファイル・セグメントをローカルに利用できるようにする（このメカニズムが失敗すると、ファイル読み込みメカニズムが失敗する）。
iii．このセグメントに対応する実名で指定された実ファイルのファイルＩＤを決定する。
iv．ファイル読み込みメカニズムを（再帰的に）使用して、このセグメントから指定されたバッファの対応するロケーションへ読み込む。
４．ファイルに書き込む
ファイル書き込みは基本となるオペレーティング・システムのファイルＩＤおよびデータ管理能力を使用する。ファイル・アクセス（前述のファイルをローカルにする）は第１の読み込みまたは書き込みまで据置き（defer）できる。
５．ファイルまたはディレクトリを消去する
与えられたパス名でファイルを消去する処理は、図２７を参照して説明する。第１に、そのファイルのローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８と領域テーブル・レコード１４２を決定する（ステップＳ４２２）。ファイルがローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を有していないか、またはロックされているか、または読み取り専用領域にあるかの場合、消去を禁止する。
実ファイル・レジストリ１２６を使用して消去しようとするファイルの実名が与えられた対応する実ファイルを識別する（ステップＳ４２４）。ファイルが実名を有していない場合（ステップＳ４２６）、ローカル・ディレクトリ拡張テーブル１２４のスクラッチ・ファイルＩＤに基づいてファイルのスクラッチ・コピーを消去し（ステップＳ４２７）、ステップＳ４２８から継続する。
ファイルが実名を有し実ファイルの使用カウントが１の場合（ステップＳ４２９）、実ファイルを消去し（ステップＳ４３０）、ステップＳ４２８から継続する。
ファイルが実名を有し実ファイルの使用カウントが１より大きい場合、使用カウントを１だけ減少する（ステップＳ４３１）。この後ステップＳ４２８から継続する。
ステップＳ４２８において、ローカル・ディレクトリ拡張テーブル・エントリ・レコードを消去し、実行した時刻とオペレーション（消去）を表わすエントリを監査ファイル１３２へ追加する。
６．ファイルまたはディレクトリをコピーする
ソースと宛先のプロセッサおよびパス名が与えられたファイルまたはディレクトリをコピーするメカニズムが提供される。ファイル・コピー・メカニズムはファイル内のデータを実際にコピーするのではなく、ファイルの実名だけをコピーする。このメカニズムは次のように実行される：
（Ａ）ソースのパスが与えられると、パスから実名を得る。このステップが失敗するとメカニズムが失敗する。
（Ｂ）実名と宛先パスが与えられると、宛先パスを実名へリンクする。
（Ｃ）ソースと宛先のプロセッサが異った実ファイル・レジストリを有している場合、宛先プロセッサの実ファイル・レジストリ・テーブル１２６にある実名のエントリを検索（または必要なら作成）する。この新規エントリのソースＩＤフィールドにソース・プロセッサの識別を入力する。
（Ｄ）実行した時刻とオペレーション（コピー）を表わすエントリを監査ファイル１３２に追加する。
このメカニズムはシステムの能力を使って、宛先がすでにデータを有している時にはソース・ロケーションから宛先ロケーションへデータのコピーを回避する。さらに、ディレクトリを凍結する能力により、このメカニズムはシステムの能力を使いあらゆるファイルの集合のコピーを作成し、これによってファイルのグループについて効率的なバージョン制御メカニズムをサポートする。
７．ファイルまたはディレクトリを移動する
ソース・パスから宛先パスへファイルを移動する（またはリネームする）メカニズムを説明する。移動オペレーションは、コピーオペレーションと同様に、実際のデータ転送を必要とせず、次のように実行される：
（Ａ）ソース・パスから宛先パスへファイルをコピーする。
（Ｂ）ソース・パスが宛先パスと異なる場合、ソース・パスを消去する。
８．ファイル状態を得る
このメカニズムは、ファイルのパス名を取りパス名に関する情報を提供する。第１に与えられたパス名に対応するローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を検索する。該当エントリが存在しない場合、このメカニズムは失敗し、それ以外の場合、ファイルとこれに対応する実ファイルについての情報をローカル・ディレクトリ拡張テーブル１２４から収集する。情報は、サイズ、型、所有者、実名、ソース、最新アクセス時刻、最新変更時刻、状態（ローカルか否か、アシミレートされたか否か、圧縮されたか否か）、使用カウント、有効期限、予約を含め、データ構造に示したあらゆる情報を含むことができる。
９．ディレクトリ内のファイルを得る
このメカニズムはディレクトリ内のファイルを列挙する。これはファイルがディレクトリ内に存在する（現存する）かどうかを調べるのに必要な時には必ず（暗黙のうちに）使用される。たとえば、ファイル・オープン、ファイル削除、ファイルまたはディレクトリのコピー、およびファイル移動オペレーティング・システム・メカニズムでは暗黙のうちに使用されるが、これは操作するファイルがディレクトリ名を含むパス名によって参照されるためである。このメカニズムは次のように動作する。
与えられたディレクトリのパス名をもつエントリ１３８について、ローカル・ディレクトリ拡張テーブル１２４を検索する。該当するエントリが見付からない場合、または見付かったエントリがディレクトリではない場合、このメカニズムは失敗する。
ローカル・ディレクトリ拡張テーブル・エントリ・レコードに対応する実ファイル・フィールドがあれば、実ファイルは凍結ディレクトリを表わしていると仮定する。凍結ディレクトリの展開プリミティブ・メカニズムを使用して、既存の実ファイルをローカル・ディレクトリ拡張テーブルのディレクトリ・エントリに展開する。
最後に、ローカル・ディレクトリ拡張テーブル１２４をもう一度検索し、今回は与えられたディレクトリに従属するディレクトリの各々を調べる。見つかった名前は結果として提供される。
リモート・メカニズム
本発明で提供されるリモート・メカニズムを説明する。リモート・メカニズムはオペレーティング・システムが他のプロセッサからの要求に応答して使用することを想起されたい。これらのメカニズムによって本発明の機能がピア・ツー・ピアのネットワークオペレーションモードで可能になる。
現在好適な実施の形態では、多数の通信プロトコルのひとつたとえばＩＰＸ／ＳＰＸまたはＴＣＰ／ＩＰなどの上で動作するリモート・プロシジャ・コール（remote procedure call：ＲＰＣ）スタイルのインタフェースを使用してプロセッサ同士が通信する。実ファイル・レジストリ・テーブル１２６またはファイル領域へのアクセスを提供する、または別のピア・プロセッサに依存している各々のピア・プロセッサは、これのピアで使用できるような多数のメカニズムを提供している。
以下のリモート・メカニズムを説明する：
１．実ファイルに位置づける。
２．実ファイルを予約する。
３．実ファイルを要求する。
４．実ファイルをリタイアさせる。
５．予約をキャンセルする。
６．実ファイルを取得する。
７．キャッシュをロックする。
８．キャッシュを更新する。
９．有効期限日付をチェックする。
１．実ファイルを検索する
このメカニズムでは、ローカル・プロセッサが特定の実ファイルを含むかどうかをリモート・プロセッサが決定できる。このメカニズムは実名と、このファイルについての要求を別のサーバへ転送するかどうかを表わすフラグで始まる。本メカニズムは図２８を参照して説明する。
第１に実ファイルがローカルに利用できるか、または実ファイルがどこにあるかの（たとえば、ソースＩＤフィールドに）何らかの表示が存在するかどうかを決定する。実ファイル・レジストリ・テーブル１２６の要求された実名を索引する（look up）（ステップＳ４３２）。
この実名について実ファイル・レジストリ・エントリ・レコード１４０が見付からない場合（ステップＳ４３４）、また要求を転送すべきでないことをフラグが表わしている場合（ステップＳ４３６）、否定的に応答する（ステップＳ４３８）。したがって、実ファイルが利用できないという作用に応答する。
一方、実ファイル・レジストリ・エントリ・レコード１４０が見付からない場合（ステップＳ４３４）で、かつこの実ファイルの要求を転送すべきであるとフラグが表わしていれば（ステップＳ４３６）、この実ファイルの要求をシステム内の他の何らかのプロセッサに転送する（ステップＳ４４２）。現在のプロセッサについてのソース・テーブルが、この実ファイルのコピーを保有すべき１つまたは２つ以上のパブリッシング・サーバ（publishing server）を認識する場合、これらのパブリッシング・サーバの各々に要求を転送する（ステップＳ４３６）。
要求された実ファイルについて実ファイル・レジストリ・エントリ・レコード１４０が見付かった場合（ステップＳ４３４）、かつエントリが実ファイルＩＤまたは圧縮ファイルＩＤを含む場合（ステップＳ４４０）、肯定的に応答する（ステップＳ４４４）。エントリが実ファイルＩＤを含む場合には、これは要求されたファイルまたはファイル・セグメントの実際の物理表現の識別またはディスク・ロケーションを提供する。エントリが圧縮ファイルＩＤを含む場合、実ファイルの圧縮バージョンを圧縮されていないバージョンの代わりに、またはこれに加えて、格納できる。このフィールドはファイルの圧縮バージョンの実際の表現の識別を提供する。
実ファイル・レジストリ・エントリ・レコード１４０が見付かった（ステップＳ４３４）が実ファイルＩＤを含まない（実際のファイルが現在のロケーションに現在のところ存在していないならファイルＩＤは存在しない）（ステップＳ４４０）場合で、かつ実ファイル・レジストリ・エントリ・レコード１４０が１つまたは２つ以上のソース・プロセッサを含む場合、また要求が転送できる場合、この実ファイルの要求を１つまたは２つ以上のソース・プロセッサへ転送する（ステップＳ４４４）。
２．実ファイルを予約する
このメカニズムでは特定の実ファイルへアクセスするためにローカル・プロセッサに依存することをリモート・プロセッサが表わすことができる。入力として実名を取る。このメカニズムについてここで説明する。
（Ａ）与えられた実ファイルに関連する実ファイル・レジストリ・エントリ・レコード１４０を検索する。エントリが存在しない場合、否定的に応答する。
（Ｂ）実ファイル・レジストリ・エントリ・レコード１４０が実ファイルＩＤまたは圧縮ファイルＩＤを含まない場合、また実ファイル・レジストリ・エントリ・レコード１４０が取り外し可能な記憶ボリュームのソースＩＤを含む場合には、このプロセッサは与えられたファイルのコピーにアクセスすることができない。否定的に応答する。
（Ｃ）送信プロセッサのＩＤを実ファイル・レジストリ・エントリ・レコード１４０の依存プロセッサのリストに追加する。肯定的に応答し、予約された実ファイルがオンラインかまたはオフラインかの表示も含める。
３．実ファイルを要求する
このメカニズムでは、リモート・プロセッサがローカル・プロセッサから実ファイルのコピーを要求できる。これには実名を必要とし、要求したプロセッサへ実ファイルを送り返すことにより肯定的に応答する。このメカニズムは次のように動作する：
（Ａ）与えられた実名に関連する実ファイル・レジストリ・エントリ・レコード１４０を見つけ出す。該当する実ファイル・レジストリ・エントリ・レコード１４０がない場合には否定的に応答する。
（Ｂ）実ファイルをローカルにするプリミティブ・メカニズムを使用して実ファイルをローカルにする。このメカニズムが失敗した場合、実ファイル要求メカニズムも失敗する。
（Ｃ）要求したリモート・プロセッサへ圧縮していないかまたは圧縮した形態のどちらかでローカルの実ファイルを送信する。実ファイルが複合ファイルの場合にはコンポーネントが送信されないことに留意されたい。
（Ｄ）リモート・ファイルが実ファイル・レジストリ・エントリ・レコード１４０の依存プロセス・リストにリストされている場合、これを削除する。
４．実ファイルをリタイアさせる
このメカニズムは、与えられた実ファイルのコピーをもはや維持する予定がないことをリモート・プロセッサが表わせるようにする。たとえば実ファイルがひとつのサーバから別のサーバへ移動している場合には、実ファイルの代替的なソースを指定できる。実名、要求したプロセッサのＩＤ、オプションとして別のソースから開始する。このメカニズムは次のように動作する：
（Ａ）実ファイル・レジストリ・テーブル１２６の実名エントリを検索する。この実名についてエントリがない場合、このメカニズムのタスクは終了する。
（Ｂ）ソース・リストで要求したプロセッサを検索し、存在していればこれを削除する。
（Ｃ）代替的なソースが提供されている場合、これを実ファイル・レジストリ・エントリ・レコード１４０のソース・リストに追加する。
（Ｄ）実ファイル・レジストリ・エントリ・レコード１４０のソース・リストに項目が無い場合、リモート・ファイルを検索するプリミティブ・メカニズムを使用してこのファイルの別のコピーについて検索する。失敗した場合、重大なエラーが発生する。
５．予約をキャンセルする
このメカニズムは、ローカル・プロセッサに格納された実ファイルへのアクセスをもはや要求しないことをリモート・プロセッサが示すことができるようにする。これは実名と要求したプロセッサのＩＤで始まり、次のように進む：
（Ａ）実ファイル・レジストリ・テーブル１２６の実名エントリを検索する。この実名についてエントリがない場合、このメカニズムのタスクは終了する。
（Ｂ）もしあれば、依存プロセッサ（dependent processors）のリストから要求したプロセッサの識別を削除する。
（Ｃ）依存プロセッサのリストがゼロになり使用カウントもゼロになっている場合、実ファイルを削除する。
６．実ファイルを取得する
このメカニズムでは、指定された実ファイルのコピーをローカル・プロセッサが行なうことをリモート・プロセッサが主張できる。これは、たとえば、キャッシュ・クライアントがファイルの新しいバージョンに書き込みたい場合に使用される。実ファイル取得のメカニズムは、データ項目とそのデータ項目のオプションの実名から始まり、次のように進む：
（Ａ）要求したプロセッサがローカル・プロセッサにデータ項目を取得するように要求する権利を有することを確認する。ない場合には、否定応答を送信する。
（Ｂ）リモート・プロセッサから送信されたデータ項目のローカル・コピーを作成する。
（Ｃ）ローカル・プロセッサの実ファイル・レジストリへデータ項目をアシミレートする。
（Ｄ）ファイルに実名が提供された場合、実名計算を回避でき、またはメカニズムは受信したファイルが送信された実名に一致することを確認できる。
（Ｅ）与えられた実ファイルのこのコピーに要求したプロセッサが依存することを表わすエントリを、実ファイル・レジストリ・レコードの依存プロセッサ・リストに追加する。
（Ｆ）肯定応答を送信する。
７．キャッシュをロックする
このメカニズムでは、リモート・キャッシュ・クライアントがローカル・ファイルをロックして、リモート・プロセッサが使用している間ローカル・ユーザまたはその他のキャッシュ・クライアントが変更できないようにする。このメカニズムはパス名で始まり、次のように進む：
（Ａ）指定されたパス名のローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を検索する。該当するエントリが存在しない場合、否定応答する。
（Ｂ）ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８が存在し、かつすでにロックされている場合、ファイルはすでにロックされていることを否定的に応答する。
（Ｃ）ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８が存在しロックされていない場合、エントリをロックする。肯定的に応答する。
８．キャッシュを更新する
このメカニズムでは、リモート・キャッシュ・クライアントはローカルファイルのロックを解除して新しい内容でこれを更新できる。これはパス名と実名で始まる。実名に対応するファイルはリモート・プロセッサからアクセスできなければならない。このメカニズムは次のように動作する。
与えられたパス名に対応するローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を検索する。該当するエントリが存在しないか、またはエントリがロックされていない場合には否定的に応答する。
パスを実名へリンクするプリミティブ・メカニズムを使用して、与えられたパス名を与えられた実名へリンクする。
ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８をロック解除して肯定的に応答する。
９．有効期限日付をチェックする
現在のまたは新規の有効期限と、考えられる別のソースを発呼側に返す。
バックグラウンド・プロセスおよびメカニズム
本発明で提供されるバックグラウンド・プロセスおよびメカニズムを説明する。バックグラウンド・メカニズムは、時に低い優先順位で実行し本発明に関する自動管理機能を提供することを意図したものであることを想起されたい。
以下のバックグラウンド・メカニズムを説明する：
１．実ファイルをミラーする。
２．領域をグルーミングする。
３．有効期限の切れたリンクをチェックする。
４．領域を検証する。
５．ソース・リストをグルーミングする。
１．実ファイルをミラーする
このメカニズムは、ファイルがミラー・グループの代替的なロケーションで利用可能になるかまたはアーカイブ・サーバにアーカイブされることを保証するために用いる。このメカニズムは、どの条件の下でファイルを移動すべきか決定するアプリケーション専用のマイグレーション／アーカイバル基準（archival criteria）（サイズ、最終アクセスからの時間、必要なコピー個数、既存の代替的なソースの個数）に依存する。実ファイルをミラーするメカニズムは以下のようにオペレーションし、指定された実ファイルを用いて、以下のステップを実行する：
（Ａ）実ファイルについて実ファイル・レジストリ・エントリ・レコード１４０のソース・リストを調べることにより、実ファイルの利用できるロケーションの数をカウントする。このステップは実ファイルのコピーが何個システムで利用できるかを決定する。
（Ｂ）実ファイルが特定のマイグレーション基準に適合する場合、ファイルのコピーを送信すべきミラー・グループ・サーバを選択する。実ファイル取得リモート・メカニズムを用いて実ファイルを選択したミラー・グループ・サーバへコピーする。選択したシステムの識別を実ファイルのソース・リストに追加する。
２．領域をグルーミングする
このメカニズムは、どこか他で利用できるデータ項目を消去することによりプロセッサで自動的に空き領域を作るために使用する。このメカニズムはアプリケーション専用のグルーミング基準（たとえば、データ識別子イルについて別のオンライン・ソースがあれば、所定の日数に渡りアクセスがなければ、また所定のサイズより大きければ削除することができる等）に依存する。このメカニズムは次のように動作する：
十分な空き領域が解放されるまで、または全てのグルーミング基準を実行し終えるまで徐々に厳しいグルーミング基準にしたがって以下のステップ（i）から（iii）を反復する。グルーミング情報を用いてどの程度の空き領域が解放されるか決定する。グルーミングが行なわれている間、グルーミング情報は消去のために選択したパス名のテーブルを含み、これらのファイルが全部消去された時に解放される空き領域の量を追跡し続ける。
（i）グルーミングを開始する（プリミティブ・メカニズムを使用）。
（ii）特定領域の各パス名について、パス名に対応する実ファイルで、実ファイルが存在し、少なくともひとつの別のソースがあり、その領域でアプリケーション独自のグルーミング基準に適合している場合、削除するファイルを選択する（プリミティブ・メカニズムを使用する）。
（iii）グルーミングを終了する（プリミティブ・メカニズムを使用）。
領域をキャッシュとして使用している場合、他のプロセッサはどれもこれが参照する実ファイルに依存せず、全ての該当する実ファイルはどこか他にミラーされる。この場合、実ファイルは無事に削除できる。キャッシュ領域では、グルーミング基準は通常ならもっとも最近アクセスされた実ファイルを最初に除去する。これは上記のステップ（ii）を実行する前に、もっとも新しいアクセス時刻で領域内の実ファイルをソートすることにより最良に行なわれる。アプリケーション専用の基準は、要求された空き領域の量に達するまで（最近もっとも使用されなかったものからはじめて）遭遇した実ファイルを全て削除のために選択するものとなる。
３．有効期限の切れたリンクをチェックする
このメカニズムは、パブリッシングされたファイルの依存性をリフレッシュすべきか決定するために使用する。以下のステップはこのメカニズムのオペレーションを説明している：
特定領域の各パス名について、パス名に対応する各実ファイルで、以下のステップを実行する：
実ファイルに対応する実ファイル・レジストリ・エントリ・レコード１４０がパブリッシング・サーバである少なくともひとつのソースを含む場合、また依存性の有効期限が過ぎているか近付いている場合、以下のステップを実行する：
（Ａ）実ファイル・レジストリ・エントリ・レコードが有効期限の切れていない他のソースを含むか決定する。
（Ｂ）サーバの実名有効期限を調べる。有効期限が延長されている場合、または別のソースが示唆される場合、実ファイル・レジストリ・エントリ・レコード１４０にソースを追加する。
（Ｃ）受け入れ可能な別のソースが上記のステップ（Ａ）または（Ｂ）で見つからなかった場合、実ファイルのローカル・コピーを作成する。
（Ｄ）期限切れソースを削除する。
４．領域の検証
このメカニズムは、実ファイル・レジストリ・テーブル１２６のデータ項目が偶発的にまたは不当に損傷されていないことを保証するために使用できる。このメカニズムのオペレーションは以下のステップで説明される：
（Ａ）指定された領域の各パス名についてローカル・ディレクトリ拡張テーブル１２４を検索し、次のステップを実行する：
（i）パス名に対応する実ファイルの名前を得る
（ii）実ファイルの実ファイル・レジストリ・エントリ・レコード１４０が、実ファイルＩＤまたは圧縮ファイルＩＤを有していない場合、これを無視する。
（iii）実ファイル検証メカニズムを使用して（以下の拡張メカニズム参照）指定された実ファイルが正しいことを確認する。
５．ソース・リストをグルーミングする
実ファイル・エントリ内のソースリストは、時々グルーミングしてミラーまたはアーカイブ・コピーが多すぎないことを保証するべきである。ファイルが消去される場合、または領域定義またはこれのミラー基準が変更される場合、影響を受ける実ファイルを調べて、多すぎるミラー・コピーが存在するかどうかを決定する必要がある。これは次のステップで行なうことができる：
影響を受ける各実ファイルについて、
（Ａ）ローカル・ディレクトリ拡張テーブルを検索して実ファイルを参照する各領域を見つけ出す。
（Ｂ）最初は空の「要求ソース（required sources）」の集合を作成する。
（Ｃ）見つかった各領域について、
（ａ）その領域のミラーリング基準を決定し、
（ｂ）実ファイルのどのソースがミラーリング基準を満たすか決定し、
（ｃ）これらのソースを要求されたソースのセットへ追加する。
（Ｄ）実ファイル・レジストリ・エントリの各ソースについて、ソースがリモート・プロセッサを（取り外し可能な媒体とは対照的に）識別する場合、かつソースがパブリッシング・サーバでない場合、かつソースが要求ソースの集合にはない場合、ソースを除去し、予約キャンセル・リモート・メカニズムを使用して、ソースで認識されたリモート・プロセッサで記録されている依存プロセッサのリストから任意のプロセッサを除去する。
拡張メカニズム
本発明で提供される拡張メカニズムについて説明する。拡張メカニズムは、オペレーティング・システム上のアプリケーション・プログラム内で実行して、特定の問題とアプリケーションに対する解決を提供するものであることを想起されたい。
以下の拡張メカニズムを説明する：
１．既存のディレクトリのインベントリを作成する。
２．取り外し可能な読取り専用ファイルのインベントリを作成する。
３．ディレクトリの同期をとる。
４．領域をパブリッシュする。
５．ディレクトリをリタイアする。
６．ディレクトリをロケーションで実体化する。
７．実ファイルを検証する。
８．アカウント目的で追跡する。
９．ライセンス目的で追跡する。
１．既存のディレクトリのインベントリを作成する
このメカニズムは、基本のオペレーティング・システムにおいて既存のオンライン・ディレクトリ内のファイルの実名を決定する。本メカニズムのひとつの目的は、既存のファイル・システムに実名メカニズムをインストールすることである。
このようなインストレーション（installation）の効果は、走査する（traverse）ファイル・システムからすぐに全ての重複ファイルを排除することである。数個のファイル・システムが単一の実ファイル・レジストリに登録されている場合、ボリューム間の重複も排除される。
（Ａ）オペレーティング・システム内の基本となるファイル・システムを走査する。遭遇した各ファイルで、ディレクトリを除いて、以下を実行する：
（i）遭遇したファイルをアシミレートする（ファイルのアシミレート・プリミティブ・メカニズムを使用する）。このプロセスは実名を計算し、データを実ファイル・レジストリ１２６に移動する。
（ii）ボリューム・ディレクトリへのパスと媒体上のファイルの相対パスから構成されるパス名を作成する。パスを実名へリンクするプリミティブ・メカニズムを使用してこのパスを計算した実名へリンクする。
２．取り外し可能な読み取り専用ファイルのインベントリを作成する
取り外し可能な読み取り専用媒体ボリューム（ＷＯＲＭディスクやＣＤ−ＲＯＭ等）にアクセスするシステムは、オンライン・コピーを作成することなくこれらのディスク上のファイルの利用可能なインベントリを作成できる。これらのオブジェクトはアーカイブの目的で、ディレクトリのオーバレイに、または他の必要性に使用できる。オペレータは、このようなボリュームについてインベントリが作成されるように要求しなければならない。
このメカニズムでは、ディスケットやＣＤ−ＲＯＭ等の取り外し可能な媒体上にデータ識別子イルの内容のインベントリを、名前、ロケーション、および作成日等のファイルの他の属性とは独立して維持することができる。
このメカニズムはボリューム上のデータがディレクトリとして表現される時に、フロッピーディスクまたはＣＤ−ＲＯＭ等の１つまたは２つ以上の取り外し可能なボリューム上のファイルのオンライン・インベントリを作成する。インベントリ・サービスは実名を用いて各々のファイルを識別し、名前、作成日、またはロケーションとは独立してデータを特定する方法を提供する。
インベントリはデータのアーカイブのため（データがすでに別のボリュームにある場合にデータをアーカイブしなくて済むようにする）、グルーミングのため（滅多にアクセスされないファイルを取り外し可能な・ボリュームから取り出すことができる場合にこれらを消去できるようにする）、バージョン制御のため（古いバージョンをコピーすることなくＣＤ−ＲＯＭの新バージョンを生成できるようにする）、およびその他の目的で使用できる。
インベントリは、ファイル名のついた各ファイルがインベントリを作ろうとするボリューム上のデータ項目を識別するメディア・インベントリにボリューム・ディレクトリを作成することにより作られる。インベントリ処理の間、データ項目は取り外し可能なボリュームからコピーされない。
オペレータは、特定のボリュームについてインベントリを作成することを要求する必要がある。一度作成すると、ボリューム・ディレクトリは他の全てのディレクトリと同様に凍結またはコピーすることができる。物理ボリュームまたはボリューム・ディレクトリのどちらかからのデータ項目は、オープン・ファイル・オペレーティング・システム・メカニズムを使用してアクセスでき、ロケーションから実ファイルを実体化するプリミティブ・メカニズムを使用して物理ボリュームからファイルを読み出すことができるようになる。
インベントリを作成するには以下のステップを行なう：
（Ａ）メディア・インベントリ内のボリューム・ディレクトリを作成してインベントリを作ろうとするボリュームに対応させる。これのコンテクスト名が特定のボリュームを識別する。
（Ｂ）そのボリュームでソース・テーブル・エントリ１４４をソース・テーブル１３０に作成する。このエントリ１４４は物理ソース・ボリュームおよびステップ（Ａ）で作成したボリューム・ディレクトリを識別する。
（Ｃ）ボリューム上のファイル・システムを走査する。遭遇した各ファイルについて、ディレクトリを除き、次のステップを行なう：
（i）ファイルの実名を計算する。プリミティブ・メカニズムを使用して、ローカル・ディレクトリ拡張テーブル１２４にファイルの実名を含むエントリを作成する。実ファイル・レジストリ・エントリ１４０のソース・フィールドは、ソース・テーブル・エントリ１４４を識別する。
（ii）ボリューム・ディレクトリへのパスと媒体上のファイルの相対パスからなるパス名を作成する。このパスは、パスを実名へリンクするプリミティブ・メカニズムを使用して計算した実名へリンクされる。
（Ｄ）全部のファイルのインベントリを作成したら、ボリューム・ディレクトリを凍結する。ボリューム・ディレクトリはそのボリュームの目次として用いる。ファイルまたはディレクトリをコピーするプリミティブ・メカニズムを用いてコピーして「オーバレイ（overlay）」ディレクトリを作成することができ、次にこれを変更することができ、読み取り専用媒体の仮想コピー（virtual copy）を編集することができるようになる。
３．ディレクトリの同期をとる
同一の開始点から導かれるディレクトリの２つのバージョンが与えられると、このメカニズムは各々からの変更を含む新規に同期したバージョンを作成する。両方のバージョンでファイルが変更されているところでは、このメカニズムは不一致（discrepancy）を取り扱うためにユーザ出口（user exit）を提供する。実名を使用することにより比較は瞬時であり、ファイルのコピーは必要とされない。
このメカニズムは、ローカル・プロセッサがリモート・プロセッサで行なった変更を考慮するようにディレクトリと同期をとらせる。この目的はローカルとリモート・プロセッサとの間で通信がない期間の後、ディレクトリのローカル・コピーを最新のものにすることである。このような期間はローカル・プロセッサがサーバから切り離されたモバイル・プロセッサ（mobile processor）の場合、または２つの離れたプロセッサが独立して実行し、夜間に更新される場合に発生することがある。
説明した同期処理の利点は、ローカルおよびリモート・プロセッサのクロックを同期することに依存しない点である。しかし、ローカル・プロセッサがリモート・プロセッサの監査ファイルにおけるポジションを追跡する必要がある。
このメカニズムは、幾つかのサイトで同一ファイルに同時に行なわれた変更を解決することができない。これが発生した場合、外部的な解決メカニズム、たとえば、オペレータの介入等が必要となる。
本メカニズムは入力として開始時刻、ローカル・ディレクトリのパス名、リモート・プロセッサの名前、およびリモート・ディレクトリ・パス名の名前を取り、以下のステップで動作する：
（Ａ）実ファイル要求リモート・メカニズムを使用してリモート・プロセッサから監査ファイル１３２のコピーを要求する。
（Ｂ）開始時刻以降、監査ファイル１３２の各エントリ１４６について、エントリがリモート・ディレクトリのファイルへの変更を示している場合、以下のステップを実行する：
（i）ローカル・ディレクトリの対応するファイルのパス名を計算する。対応するファイルの実名を決定する。
（ii）ローカル・ファイルの実名が監査ファイルの古い実名と同じ場合、またはローカル・ファイルが存在せず監査エントリで新規ファイルが作成されることを示している場合、パスを実名にリンクするプリミティブ・メカニズムを使用して監査ファイルの新規の実名をローカルのパス名にリンクする。
（iii）それ以外の場合、ローカル・パス名、リモート・パス名、リモート・プロセッサ、および変更時刻を表わすメッセージをオペレータへまたは問題解決プログラムへ送信することによる同期には問題があることに注意されたい。
（Ｃ）同期が完了した後、最終変更の時刻を記録する。この時刻は次回このディレクトリを同じリモート・プロセッサと同期する際に新規の開始時刻として使用する。
４．領域をパブリッシュする
領域パブリッシング・メカニズムは、プロセッサが限られた時間間隔で領域内のファイルをあらゆるクライアント・プロセッサへ提供するようにさせる。
本サービスの目的は、クライアント・プロセッサがパブリッシング・プロセッサに予約をする必要を除去することにある。これによってパブリッシング・プロセッサが非常に多数のクライアントにサービスできるようになる。
領域をパブリッシュする場合、領域内の全ファイルに対して有効期限が定義されて、各々のファイルに対するパブリッシング・システムの実ファイル・レジストリ・エントリ・レコード１４０に伝えられる。
たとえばファイル・コピー・オペレーティング・システム・メカニズムを使用してリモート・ファイルをコピーする場合、有効期限はクライアントの実ファイル・レジストリ・エントリ・レコード１４０のソース・フィールドにコピーされる。ソースがパブリッシング・システムの場合、依存性を作成する必要はない。
クライアント・プロセッサは時々バックグラウンドで期限切れのリンクをチェックし、これらのファイルにまだアクセスできることを保証する必要がある。これについては期限切れリンクのチェックのバックグラウンド・メカニズムで説明する。
５．ディレクトリをリタイアする
このメカニズムは、ディレクトリ内の実ファイルまたは少なくともこれの依存性が、これらのファイルに依存する全てのクライアント・プロセッサが依存性を削除したことを保証した後で、安全に除去されることを可能にする。ディレクトリ内のファイルはこの処理では実際に消去されない。ディレクトリはファイル消去オペレーティング・システム・メカニズムで消去できる。
このメカニズムは任意のディレクトリのパス名と、オプションとしてクライアントが使用する好適な別のソース・プロセッサの識別を取る。本メカニズムは以下のステップを実行する：
（Ａ）ディレクトリを走査する。ディレクトリ内の各々のファイルについて、以下のステップを実行する：
（i）ファイルの実名をこれのパスから得て、実名に関連する実ファイル・レジストリ・エントリ・レコード１４０を検索する。
（ii）実ファイルについて代替的なソースを決定する。ＴＦＲエントリのソースＩＤフィールドが好適な代替的なソースを含む場合、これが代替的なソースである。これを含まないが、代替的な何らかのソースを含む場合には、これが代替的なソースである。代替的なソースを全く含まない場合、代替的なソースはない。
（iii）実ファイル・レジストリ・エントリ・レコード１４０の各々の依存プロセッサについて、そのプロセッサに実ファイルをリタイアするように問い合せて、リモート・メカニズムを使用して代替的なソースが決定される場合は代替的なソースを指定する。
６．ディレクトリをロケーションで実体化
このメカニズムは、ユーザまたはオペレーティング・システムが何らかのソース・ロケーションから任意のロケーションにある実ファイル・レジストリ・テーブル１２６へファイルのコピーを強制することができるようにする。このメカニズムの目的は、ソース・ロケーションがアクセス不能になった場合にそのファイルがアクセスできるように保証することである。これはたとえばソースまたは任意のロケーションがモバイル・コンピュータ上にあるか、または取り外し可能な媒体上にあるか、またはソースへのネットワーク接続が期限切れで利用できなくなるか、またはソースがリタイアしている場合に発生することがある。
本メカニズムは任意のディレクトリ内のサブディレクトリを除く各ファイルについて以下のステップで提供する：
（Ａ）ファイルのパス名が与えられたローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８を得る。ローカル・ディレクトリ拡張テーブル・エントリ・レコード１３８の実名を得る。このサービスはすでにアシミレートされていない場合にファイルをアシミレートする。
（Ｂ）任意のロケーションに対応する実ファイルを実体化する。このサービスによりリモート・システムまたは取り外し可能な媒体から任意のロケーションへファイルがコピーされる。
７．実ファイルの検証
このメカニズムは、実ファイル・レジストリ・テーブル１２６のデータ項目が本当に実名の与えられた正しいデータ項目であるかを検証するために使用する。この目的は、デバイス・エラーや、不当な変更、またはその他の問題から保護することである。
エラーが発見された場合、システムは任意の名前を有する実ファイルについて別のソースを検索することにより自分で「治療（heal）」する能力を有している。またエラーが他のシステムに伝搬しなかったことを確認し、問題を記録するかまたはコンピュータ・オペレータにこれを提示することも望ましい。これらの詳細については本明細書において説明しない。
実ファイル・レジストリ・テーブル１２６に入っていないデータ項目を検証するには、前述した実名計算プリミティブ・メカニズムを使用する。
基本メカニズムは実名からはじめて、以下のステップで動作する：
（Ａ）与えられた実名に対応する実ファイル・レジストリ・エントリ・レコード１４０を検索する。
（Ｂ）実ファイル・レジストリ・エントリ・レコード１４０に実ファイルＩＤがある場合にはこれを使用する。それ以外の場合には検証すべきファイルが存在しないことを示す。
（Ｃ）データ項目のファイルＩＤを与えられたデータ項目の実名を計算する。
（Ｄ）計算した実名が与えられた実名と等しいことを確認する。
（Ｅ）実名が等しくない場合、実ファイル・レジストリ・テーブル１２６にエラーが存在する。実ファイル・レジストリ・エントリ・レコード１４０から実ファイルＩＤを削除してどこか他に置く。実ファイル・レジストリ・エントリ・レコード１４０にエラーが含まれていたことを示す。
８．アカウント目的の追跡をする
このメカニズムはどのファイルがシステムに格納されたか、またはひとつのシステムから別のシステムへ送信されたかを確実に知る方法を提供する。本メカニズムは、単純にビット数によってではなく格納または送信したデータの識別に基づいて課金が行なわれる、値に基づくアカウント・システム（value-based accounting system）の基盤として使用できる。
本メカニズムではデータ項目の名前、日付、またはその他の属性と関係なく、所有者による内容にしたがって特定のデータ項目の保有をシステムが追跡でき、アカウント目的で内容により特定のデータ項目およびファイルの使用を追跡する。実名はこの目的で簡潔にかつユニークに各ファイルを識別できるようにする。
ファイルの識別の追跡は、アカウント・ログ１３４を保持しアカウントまたは課金目的でこれを処理する必要がある。本メカニズムは次のステップで動作する：
（Ａ）ファイルが作成されるかまたは消去されるたびに、たとえば監査ファイル・エントリ処理プリミティブ・メカニズムにおいて監査エントリをモニタすることにより注意する。このようなイベントに遭遇すると、責任者（responsible party）と作成または消去されたファイルの識別とを表わすエントリ１４８をアカウント・ログ１３４に作成する。
（Ｂ）ファイルを送信するたびに、たとえばファイルが実ファイル要求リモート・メカニズムでまたは実ファイル取得リモート・メカニズムでファイルがコピーされた時、責任者、ファイルの識別、およびソースと宛先のプロセッサを示すエントリをアカウント・ログ１３４に作成する。
（Ｃ）アカウント・プログラムを時々実行してアカウント・ログ１３４を処理し、各責任者のアカウント・レコードにイベントを分配する。アカウント・レコードは課金のために最終的に要約することができる。
９．ライセンス目的で追跡する
本メカニズムは、ライセンスされたファイルが不正使用者によって使用されないように保証する。実名はライセンスされたものを識別する安全な方法を提供する。本サービスは、内容により、その内容を開示することなく、特定のファイルの保有の証明を可能にする。
有効なライセンスの実施（enforcing）は、能動的（たとえば、許可なくファイルへのアクセスを提供するのを拒絶することにより）または受動的（たとえば、正しい許可を有していないユーザのレポートを作成することにより）にすることができる。
ライセンス認証を実行するひとつの可能な方法は、使用者システムの監査をしばしば行なうことである。本明細書で説明しているサービスは実名に基づいてこのような監査をサポートするもので、以下のステップで行なう：
（Ａ）ライセンスされた各製品について、製品のキー・ファイル（したがってその製品を使用するために必要なファイル、また他の製品には見られないファイル）の実名をライセンス・テーブル１３６に記録する。代表的には、ソフトウェア製品について、これには主となる実行可能イメージ、およびおそらくは他の主要なファイル、たとえばクリップ・アート、スクリプト、またはオンライン・ヘルプが含まれる。また、ファイルのコピーを保有する許可を受けた各システムの識別を記録する。
（Ｂ）時々、各ユーザのプロセッサの内容をライセンス・テーブル１３６に対して比較する。ライセンス・テーブルの実名の各々について、以下を実行する：
（i）ユーザ・プロセッサがファイルのコピーを保有する許可を得ているのでない限り、ユーザ・プロセッサがファイルのコピーを保有していないことを実ファイル検索メカニズムを使用して確認する。
（ii）ユーザ・プロセッサが保有する許可を得ていないファイルを有していると分かった場合、ライセンス侵害テーブル（license violation table）にユーザ・プロセッサおよび実名を記録する。
オペレーションにおけるシステム
前述のメカニズムが与えられた場合に、どのように本発明が要件および能力に適合するかどうかを示すため、これらのメカニズムを使用する典型的なＤＰシステムのオペレーションを説明する。
オペレーションにおいて、本発明を用いるＤＰシステムのデータ項目（たとえば、ファイル、データベース・レコード、メッセージ、データ・セグメント、データ・ブロック、ディレクトリ、オブジェクト・クラスのインスタンス、その他）は実質的にユニークな識別子（実名）によって識別され、識別子はデータ項目のデータの全部かつデータ項目のデータにのみ依存する。実名計算およびデータ項目のアシミレートのプリミティブ・メカニズムはこの属性をサポートする。何らかの任意のデータ項目について、実名計算プリミティブ・メカニズムを使用して、そのデータ項目に対して実質的にユニークな識別子または実名を決定できる。
さらに、本発明を組み込んでいるＤＰシステムのオペレーションにおいて、データ項目の多数のコピーが防止される（何らかの理由、たとえばフォールト・トレラント・システム（fault-tolerant system）におけるバックアップまたはミラー・コピーで必要とされない限り）。データ項目の多数コピーは多数の名前で同一のデータ項目を参照する場合でも回避される。データ項目のアシミレートおよび新規実ファイル・プリミティブ・メカニズムはこの属性をサポートする。データ項目のアシミレート・プリミティブ・メカニズムを使用すると、すでにシステム内に、実ファイル・レジストリ・テーブル１２６のエントリで示されるようにデータ項目が存在する場合、この存在は本メカニズムにより発見され、複製データ項目（新規データ項目）は除去される（または追加されない）。したがって、たとえば、システム上にフロッピー・ディスクからデータ・ファイルをコピーしようとする場合、データ・ファイルの実名に基づいて、そのデータ・ファイルがシステム内にすでに存在すると分かった場合（同一のまたは何らかの別の名前で）、複製コピーはインストールされない。データ項目が現在の名前以外の何らかの別の名前でシステムにインストールされていた場合、パスを実名へリンクするプリミティブ・メカニズムを使用して、他の（または新規の）名前をすでに存在するデータ項目へリンクできる。
一般に、本発明のメカニズムは、あるロケーションで実際のデータ項目のコピーがすでに存在している場合に、そのデータ項目のそのロケーションへの再生成が防止されるような方法で動作する。フロッピー・ディスクからのコピーの場合、データ項目（ファイル）はそれが複製であると決定できる前に（スクラッチ・ファイルへ）コピーする必要がある。これはひとつのプロセッサだけが関係しているためである。他方で、マルチプロセッサ環境またはＤＰシステムで、各プロセッサはそのプロセッサ上のデータ項目の実名のレコードを有している。データ項目をＤＰシステム内の別のロケーション（別のプロセッサ）にコピーしようとする場合、必要とされることはコピーする以前にデータ項目の実名を調べることが全てである。同一の実名を有するデータ項目がすでに宛先ロケーション（プロセッサ）に存在している場合、データ項目をコピーする必要はない。すでに宛先ロケーションにローカルに存在しているデータ項目が宛先ロケーションにさらにコピーされる場合（たとえば、リモート・システムがデータ項目の実名を有していないため、または匿名のデータのストリームとして到着しているため）、データ項目をアシミレートするプリミティブ・メカニズムはデータ項目の複数コピーが作成されないように留意されたい。
大きなデータ項目（複合データ項目）の実名はデータ項目のコンポーネントの実名に由来しこれに基づいていることから、データ項目全体のコピーが防止できる。大きなデータ項目のコンポーネントの幾つか（または全部）が宛先ロケーションにすでに存在し得るため、これらのコンポーネントのうち存在していないものだけをコピーする必要がある。この属性は実名が決定される方法に由来する。
ファイルまたはディレクトリのコピー・オペレーティング・システム・メカニズムでファイルをコピーする時、ファイルの実名だけが実際に複製される。
（ファイル・オープン・オペレーティング・システム・メカニズムを用いて）ファイルを開く場合、実ファイルをローカルにするプリミティブ・メカニズム（直接的に、またはスクラッチ・ファイル作成プリミティブ・メカニズムを経由して間接的にのどちらかで）を使用してファイルのローカル・コピーを作成する。ファイル・オープン・オペレーティング・システム・メカニズムは実ファイルをローカルにするプリミティブ・メカニズムを使用し、これはロケーションから実ファイルを実体化するプリミティブ・メカニズムを使用し、これがさらに実ファイル要求リモート・メカニズムを使用する。
実ファイル要求リモート・メカニズムは、ひとつのプロセッサから別のプロセッサへ単一のデータ項目だけをコピーする。そのデータ項目が複合ファイルの場合、これの内容セグメントはコピーされず、間接ブロックだけがコピーされる。セグメントは読み込まれる時（またはそれ以外に必要とされる時）だけコピーされる。
ファイルを読み込むオペレーティング・システム・メカニズムは実際にデータを読み込む。ファイルを読み込むメカニズムは複合ファイルと間接ブロックに注意し、ロケーションから実ファイルを実体化するプリミティブ・メカニズムを使用してコンポーネント・セグメントがローカルに利用可能であるように保証し、その上でオペレーティング・システム・ファイル・メカニズムを使用してローカル・ファイルからデータを読み込む。
したがって、複合ファイルがリモート・システムからコピーされる場合、実名だけがコピーされる。これを開く場合、これの間接ブロックだけがコピーされる。対応するファイルを読み込む場合、要求されたコンポーネント・セグメントが実体化され、そのためコピーされる。
オペレーションにおいて、データ項目はその存在するロケーションとは無関係に識別（実名）を参照してアクセスできる。任意のデータ識別子または実名に対応する実際のデータ項目または実ファイルは、システム内のどこにあっても良い（即ち、ローカルに、リモートに、オフラインで、等）。要求された実ファイルがローカルに存在する場合、ファイル内のデータにアクセスできる。データ項目がローカルに存在しない場合、これが存在するところから取得することができる多数の方法が存在する。実ファイル・レジストリ・テーブルのソースＩＤフィールドを使用すると、任意の実名に対応する実ファイルのコピーのロケーションを決定できる。ロケーションから実ファイルを実体化するプリミティブ・メカニズムは、実名と実ファイルを含むソース・ロケーション（プロセッサまたは媒体）の名前が与えられれば、実ファイルのローカル・コピーを作成しようと試みる。一方で、何らかの理由によって実ファイルのコピーがどこに存在するか分からない場合、またはソースＩＤフィールドで識別されるプロセッサが要求された実ファイルで応答しない場合、データ項目を要求するプロセッサは、接触できるシステム内の全部のプロセッサから、実ファイル要求リモート・メカニズムを用いてデータ項目の一般要求を行なうことができる。
結果として、本システムはデータＩＤを参照して、現在のロケーションと無関係に、全てのデータ項目へ透過的なアクセスを提供する。
オペレーションにおいて、システム内のデータ項目は検証したり完全性をチェックできる。これは実名が決定される方法による。これはセキュリティ（security）目的、たとえばウィルスのチェックのためや別のロケーションから取り込まれたデータが所望のかつ要求したデータであることを検証するために使用できる。たとえば、システムはシステム上にある全ての実行可能なアプリケーションの実名を記憶しておき、定期的にこれらのアプリケーションの各々の実名を再決定して、記憶している実名と一致することを確認する。実名の何らかの変化はシステム内の混乱を潜在的に警告するもので、さらに調査することができる。領域の検証バックグラウンド・メカニズムと実ファイル検証拡張メカニズムはこのオペレーションモードを直接サポートする。領域検証メカニズムは実ファイル・レジストリ内のデータ項目が偶発的にまたは意図的に損傷されなかったことを保証するために使用する。実ファイル検証メカニズムは、実ファイル・レジストリ内のデータ項目が本当に実名の与えられた正しいデータ項目であるかを検証する。
ＤＰシステムのどこに（したがって他のプロセッサまたはロケーションに）データ項目のコピーがあるかプロセッサが決定すると、そのプロセッサは他のプロセッサまたはロケーションにそのデータ項目のコピーを保持させる必要がある。たとえば、プロセッサがデータ項目のローカル・コピーを削除してローカルに利用可能な空き領域を作りたい時に、どこか他から必要な時にデータを取り込むことを依頼できると分かる。このため、システムではプロセッサがリモート・ロケーションで（リモート・メカニズムを使用して）実ファイルの予約（および予約のキャンセル）ができる。このようにすると、リモート・ロケーションは別のロケーションがそのロケーションでの実ファイルの存在に依存していると通知される。
本発明を使用するＤＰシステムは、システム内の多数のロケーションでデータ項目のある程度の量の冗長性を提供することにより障害対策システムにすることができる。実ファイル取得および実ファイル予約リモート・メカニズムを使用すると、特定のプロセッサはデータ項目を別のプロセッサにコピーしてこれらを予約することにより、自分自身の形態のフォールト・トレランス（fault-tolerance）を実装できる。しかし、システムは実ファイルのミラー・バックグラウンド・メカニズムも提供してシステム内のどこかに利用できる実ファイルのミラー（コピー作成）ができる。あらゆる度合の冗長性（プロセッサの個数またはシステム内のロケーションの個数で制限される）を実現できる。結果として、本発明はプロセッサのネットワーク内で所望の度合またはレベルの冗長性を維持し、異なるロケーションにデータ項目の多数コピーが存在することを保証することで、いずれか特定のプロセッサの障害から保護する。
本発明の各種の特徴およびメカニズムを実現するために使用されるデータ構造は、各種メカニズムとの関連において本発明を使用するＤＰシステムの記憶方式およびポリシーを実施するために使用できる有用な各種情報を記憶する。たとえば、データ項目（またはデータ項目のグループ）のサイズ、古さ（age）、ロケーションが提供される。この情報はデータ項目をどのように処理するか決定するために使用できる。たとえば、プロセッサは、これらのデータ項目の他のコピーがシステム内の他の場所に存在する場合に、ある程度の古さまでのデータ項目全部のローカル・コピーを削除するポリシーを実施できる。ローカル・ディレクトリ拡張テーブルの最終アクセスまたは変更時刻を使用して古さ（または古さについての変化）を決定でき、データ項目の他のコピーの存在は安全フラグまたはソースＩＤのどちらかから、またはそのデータ項目のコピーをシステム内の他のどのプロセッサが有するか調べて、少なくともそれらコピーのひとつを予約することにより、決定できる。
オペレーションにおいて、システムはデータ項目をユーザがどのように名付けたかとは無関係に（またはデータ項目が名前を持っているかとも無関係に）データ項目を追跡できる。システムは別の名前（別のまたは同一のロケーションで）を持つデータ項目および同じ名前を持つ別のデータ項目も追跡できる。データ項目はデータの内容に関わりなく、項目内のデータで識別されるので、ＤＰシステムにおけるネーミングの一貫性の無さの問題は克服される。
オペレーションにおいて、システムはデータ項目をパブリッシングでき、ネットワーク内の他の、恐らく匿名（anonymous）のシステムがそのデータ項目にアクセスしこれらのデータ項目の利用性に依存することができる。実名はグローバルにユニークな識別子で単純にこれをコピーすることでパブリッシュ（publish）できる。たとえば、ユーザはシステムＡに実名Ｎ（たとえば１６進数列として）を有するファイルの文字表現を作成し、これをコンピュータ電子掲示板（bulletin board）へポストすることができる。システムＢの別のユーザは、パスを実名へリンクするプリミティブ・メカニズムを用いることでこの実名Ｎについてディレクトリ・エントリＦを作成できる（これ以外にも、アプリケーションはユーザから実名を隠蔽するが、同一のパブリッシング転送サービスを提供するように開発できる）。
システムＢのプログラムが実名Ｎにリンクされたパス名Ｆを開こうとすると、リモート・ファイル検索プリミティブ・メカニズムが使用されて実ファイル検索リモート・メカニズムを使用し１つまたは２つ以上のリモート・プロセッサ、たとえばシステムＡで実名Ｎを検索する。システムＢがシステムＡにアクセスできる場合、実ファイルを実体化して（ロケーションから実ファイルを実体化するプリミティブ・メカニズムを使用する）ローカルに使用できるようになる。これ以外に、システムＢはあらゆるパブリックに利用できる実名サーバにアクセスすることで、そのサーバが最終的に要求をシステムＡへ転送できれば、実名Ｎを発見できる。
ローカル・サーバのクライアントは（実ファイル予約リモート・メカニズムを使用して）任意の実ファイルに依存しているので、幾つかのクライアントがこれへのアクセスを要求している限りサーバ・レジストリから実ファイルが消去されないことを示すことができる。（実ファイル・リタイア・リモート・メカニズムを使用してクライアントが任意の実ファイルをもはや必要としないことを示す）。
一方、パブリック・サーバ（public server）は多数のクライアントへ、また恐らくは匿名のクライアントへ、各クライアントの依存性追跡のオーバヘッドを増加させることなく、アクセスを提供したいことがある。したがって、パブリック・サーバはこれのレジストリ内の実ファイルに有効期限を提供できる。これによってクライアント・システムはパブリック・サーバ上の実ファイルへの参照を安全に維持できる。期限切れリンクのチェック・バックグラウンド・メカニズムによって、パブリック・サーバのクライアントは、パブリック・サーバ上の依存性が安全かを時々確認することができる。
本発明のこの態様の変化において、システムへ新たに接続された（または何らかの不在の後に再接続された）プロセッサはサーバ・プロセッサからシステム内の全部のデータ（または必要とするデータ）の現行バージョンを要求することでこれを取得できる。このような何らかのプロセッサは、必要とするディレクトリにディレクトリの同期拡張メカニズムを使用するだけで、（ルート・ディレクトリで始まる）ディレクトリの全部を更新または再同期する要求を送信できる。
アカウント・ログまたは他の何らかのユーザが提供したメカニズムを使用すると、ユーザはある時刻にあるデータ項目の存在を証明できる。任意の日付の（または何らかの任意時刻に）システム内の実名全部のリストをパブリッシングすることにより、そのリストを後でたどって、そのリストがパブリッシュされた時刻に、特定のデータ項目がシステム内に存在していたことを示すことができる。このようなメカニズムは、たとえば研究ノートその他を追跡して発明の概念の日時を証明するのに有用である。このようなメカニズムはまた特定の日付と時刻にデータ項目の保有の証明ができる。
アカウント・ログファイルもアカウント目的で内容により特定のデータ項目およびファイルの使用を追跡できる。たとえば、情報ユーティリティ企業はコンピュータ・システムを経由して記憶され送信されるデータ項目のデータＩＤを決定し、これらの識別を用いて（実質的にユニークな識別子で定義されるように）送信されるデータ項目の識別に基づき顧客への請求を提供できる。特定の実ファイルの記憶および送信のための価格割り当ては情報ユーティリティおよび／またはそのデータ供給者によって行なわれる。この情報はアカウント・ログファイルの情報と定期的に組み合されて顧客ステートメントを作成する。
本発明を用いるＤＰシステムにおけるデータ項目のバックアップは、データ項目の実名に基づいて行なうことができる。実名を用いるバックアップを追跡することで、バックアップの重複が防止される。オペレーションにおいて、システムはすでにバックアップしたデータ項目のデータ識別子のバックアップ・レコードを保持し、ファイルまたはディレクトリのコピー・オペレーティング・システム・メカニズムを起動してデータ識別子がバックアップ・レコードに記録されていないデータ項目だけをコピーする。一度データ項目がバックアップされれば、データ項目の識別子に基づいてバックアップ・ロケーションから取り出すことにより復元することができる。バックアップによって作成されたバックアップ・レコードを使用してデータ項目を識別することで、たとえば実ファイルをローカルにするプリミティブ・メカニズムを用いてデータ項目を取得できる。
オペレーションにおいて、システムはサーバからのデータ項目をキャッシュするために使用できるので、最近アクセスされたデータ項目だけを保持すればよい。この方法でオペレーションするには、リモートのローカル・ディレクトリ拡張テーブルを（キャッシュ・サーバから）備えるローカル・レジストリ（キャッシュ）を有するようにキャッシュ・クライアントを設定する。ファイルが開かれる（または読み出される）場合はいつでも、ローカル・ディレクトリ拡張テーブルを用いて実名を識別し、実ファイルをローカルにするプリミティブ・メカニズムがローカル・レジストリを検査する。ローカル・レジストリがすでにコピーを有している場合、ファイルはすでにキャッシュされている。それ以外の場合、実ファイル検索リモート・メカニズムを用いてファイルのコピーを取得する。このメカニズムはキャッシュ・サーバに問い合せ実ファイル要求リモート・メカニズムを用いてローカル・コピーを作成するので、キャッシュを効率的にロードできる。
キャッシュのグルーミング・バックグラウンド・メカニズムはキャッシュをフラッシュ（flush）し、最近使用されていないファイルをキャッシュ・クライアントの実ファイル・レジストリから削除する。キャッシュ・クライアントでファイルが変更されている間、キャッシュのロックおよびキャッシュ更新リモート・メカニズムは他のクライアントが同一ファイルの変更を行なうのを防止する。
オペレーションにおいて、システムがデータ項目のキャッシュに使用されている時、キャッシュの一貫性を維持する問題が回避される。
キャッシュにアクセスするためとサーバからキャッシュを埋めるためには、所望のデータ項目を識別するためにキーが必要とされる。通常、キーは名前またはアドレス（この場合、ファイルのパス名であり得る）である。このようなキーに関連するデータが変更された場合、クライアントのキャッシュは一貫性が無くなるので、キャッシュ・クライアントがその名前を参照する時、間違ったデータを取り出すことになる。キャッシュの一貫性を維持するためには、サーバ上で変更が起った時にはすぐに全てのクライアントに通知する必要がある。
本発明の実施の形態を用いることで、キャッシュ・キーはこれが表わすデータをユニークに識別する。名前の関連したデータが変化する時、キーそれ自身も変化する。したがって、キャッシュ・クライアントが任意のファイル名に関連した変更されたデータにアクセスしたい場合、キャッシュにある古いファイル内容へのキーではなく新しいキー（新規ファイルの実名）を使用する。クライアントは常に正しいデータを要求し、キャッシュ内の古いデータは最終的に陳旧化しキャッシュをグルーミングするバックグラウンド・メカニズムによりフラッシュされる。
キャッシュ・サーバ上の変化が発生した時にクライアントに即時通知する必要はないことから、本発明は単一サーバが他でできるよりも大多数のクライアントをサポートすることができるようになる。
オペレーションにおいて、システムはデータ項目が作成または変更されるとデータ項目を自動的にアーカイブする。ファイルが作成または変更された後、ファイルを閉じるオペレーティング・システム・メカニズムが監査ファイル・レコードを作成し、これが監査ファイル・エントリの処理プリミティブ・メカニズムにより最終的に処理される。このメカニズムは新規実ファイル・プリミティブ・メカニズムを新規に作成された全てのファイルに使用し、これがさらに、実ファイルがミラーまたはアーカイブ領域にある場合には、実ファイルをミラーするバックグラウンド・メカニズムを使用する。このメカニズムにより新規ファイルの１つまたは２つ以上のコピーがリモート・プロセッサに作成される。
オペレーションにおいて、システムはデータ項目のあらゆる集合を効率的に記録し保持することができる。ディレクトリの凍結プリミティブ・メカニズムは、ディレクトリ内のファイルとサブディレクトリ全部を識別する実ファイルを作成する。この実ファイルは構成要素の実名を含むことから、凍結した時刻におけるディレクトリ・ツリーの正確な内容を表わしている。凍結したディレクトリはこれに保持されたコンポーネントをコピーできる。
実ファイル取得リモート・メカニズム（ミラーリングとアーカイブで使用される）は、複合データ項目のコンポーネント・セグメントおよび実ファイルの全部が実際にリモート・システムへコピーされることを保証することで、ディレクトリのツリー構造を保持する。当然のことながら、リモート・システムのレジストリにすでに存在するデータ項目では転送が必要ない。
オペレーションにおいて、システムはデータ項目の集合のコピーを効率的に作成し、データ項目のグループについてバージョン制御メカニズムをサポートする。
ディレクトリの凍結プリミティブ・メカニズムは、データ項目の集合を作成するために使用される。凍結ディレクトリで参照される構成ファイルおよびセグメントはレジストリに保持され、ディレクトリが凍結されるたびに構成要素のコピーを行なう必要がない。
パス名をトラバースする場合はいつでも、ディレクトリ内のファイル取得オペレーティング・システム・メカニズムが使用され、凍結ディレクトリに遭遇すると、凍結ディレクトリの展開プリミティブ・メカニズムを使用する。
凍結ディレクトリはひとつのパス名から別のパス名へ、単にこれの実名をコピーすることで、効率的にコピーできる。ファイル・コピー・オペレーティング・システム・メカニズムを用いて凍結ディレクトリをコピーする。
したがってディレクトリの異なるバージョンのコピーを効率的に作成し、これによって履歴の記録（したがってバージョン制御システム）を作成することができる。
オペレーションにおいて、システムは任意の取り外し可能な媒体、たとえばディスケットまたはＣＤ−ＲＯＭ上に位置するデータ項目全部のローカル・インベントリを保持できる。インベントリは名前、ロケーション、作成日等のデータ項目の他の属性とは独立している。
既存のディレクトリのインベントリ作成拡張メカニズムは、ディレクトリ内のファイル全部について実ファイル・レジストリ・エントリを作成する方法を提供する。このインベントリの使用法のひとつは、バックアップ・レコード情報を持つ実ファイルレジストリをプリロードする方法である。インベントリを作成したボリューム上にあるレジストリ内のこれらのファイル（たとえば以前に導入されたソフトウェア）は、他のボリュームへバックアップしなくて済む。
取り外し可能な読み取り専用ファイルのインベントリ作成拡張メカニズムは媒体上のファイルの実名を決定するだけでなく、凍結したディレクトリ構造内の各ファイルについてディレクトリ・エントリを記録する。このディレクトリをコピーし変更することで、オンライン・パッチまたは既存の読み取り専用ファイルの多少の変更を作成することができる。たとえば、変更されていないファイルが実際にはＣＤ−ＲＯＭに存在しかつ変更されたファイルだけがオンラインになっているように、変更されたＣＤ−ＲＯＭのオンライン表現を作成することができる。
オペレーションにおいて、システムは名前、日付、またはデータ項目のその他の属性とは無関係に所有者による内容にしたがって特定のデータ項目の保有を追跡し、特定のデータ項目およびファイルの使用をアカウント目的で内容により追跡する。アカウント目的での追跡拡張メカニズムを使用することにより、システム上に格納されているまたはひとつのシステムから別のシステムへ送信されたファイルがどれかを確実に知る方法を提供する。
リレーショナルおよびオブジェクト指向データベースにおける実名
本発明の好適実施の形態をファイル・システムの枠内で提示したが、実名の発明はリレーショナルまたはオブジェクト指向データベースにおいても等しく価値がある。実名を使用するリレーショナルまたはオブジェクト指向データベース・システムは、本発明を使用するファイル・システムと同様の利益を有する。たとえば、このようなデータベースでは重複レコードの効率的な排除、レコード用のキャッシュのサポート、キャッシュ一貫性維持の処理の簡略化、レコードへのロケーション非依存アクセスの提供、レコードのアーカイブおよび履歴の保持、遠方または切断されたシステムまたはデータベースとの同期が行なえるようになる。
前述のメカニズムはこのようなデータベース環境で用いるように簡単に変更できる。実名レジストリはデータベース・レコードのリポジトリとして使用される。レコードへの全ての参照はレコードの実名を経由する（ローカル・ディレクトリ拡張テーブルは所望のレコードのユニークな識別子として実名を使用する１次インデックスの一例である）。
このようなデータベースにおいて、レコードの挿入、更新、消去のオペレーションは第１にレコードをレジストリにアシミレートし、次に１次キー・インデックスを更新して、内容へのポインタに実名を使用することでレコードのキーをその内容へマッピングすることができる。
好適実施の形態で説明したメカニズム、または同様のメカニズムはこのようなシステムで使用される。これらのメカニズムは、たとえば、実名を計算するため、実ファイルをアシミレートし、検索し、実体化し、消去し、コピーし、移動するため、実ファイルをミラーリングするため、実ファイルのキャッシュを保持するため、実ファイルをグルーミングするためのメカニズムおよび実質的にユニークな識別子の使用に基づくその他のメカニズムを含み得る。
本発明はもっとも具体的かつ好適な実施の形態であると現時点で考えられるものとの関連で説明したが、本発明は開示された実施の形態に制限されるべきものではなく、むしろ逆に、添付の請求項の趣旨と範囲に含まれる各種の変更および等価な構成を包括することを意図していることは理解されるべきである。
【図１】
0003865775.tif 000011
【図２】
0003865775.tif 000012
【図３】
0003865775.tif 000013
【図４】
0003865775.tif 000014
【図５】
0003865775.tif 000015
【図６】
0003865775.tif 000016
【図７】
0003865775.tif 000017
【図８】
0003865775.tif 000018
【図９】
0003865775.tif 000019
【図１０（ａ）】
0003865775.tif 000020
【図１０（ｂ）】
0003865775.tif 000021
【図１１】
0003865775.tif 000022
【図１２】
0003865775.tif 000023
【図１３】
0003865775.tif 000024
【図１４】
0003865775.tif 000025
【図１５】
0003865775.tif 000026
【図１６】
0003865775.tif 000027
【図１７】
0003865775.tif 000028
【図１８】
0003865775.tif 000029
【図１９】
0003865775.tif 000030
【図２０】
0003865775.tif 000031
【図２１】
0003865775.tif 000032
【図２２】
0003865775.tif 000033
【図２３】
0003865775.tif 000034
【図２４】
0003865775.tif 000035
【図２５】
0003865775.tif 000036
【図２６】
0003865775.tif 000037
【図２７】
0003865775.tif 000038
【図２８】
0003865775.tif 000039