JPH035848A - 分散データ処理システムにおけるフアイル属性の管理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、通信リンクによって接続された複数のデータ
処理システムに関する。特に分散ネットワーク環境にお
けるローカル処理システムと遠隔処理システムとの間で
のファイルのアクセスに関する。

Ｂ、従来技術 第５図に示すように、分散ネットワーク環境１は、通信
リンク又はネットワーク３により接続された２以上のノ
ードＡ、Ｂ、Ｃから構成される。

ネットワーク３は、ローカル・エリア・ネットワーク（
ＬＡＮ）又は広域ネットワーク（ＷＡＮ）のどちらでも
よい。

ノードＡ、Ｂ、Ｃには、ワークステーション等の処理シ
ステムＩＯＡ、ＩＯＢ、ＩＯＣが存在しうる。これら処
理システムＩＯＡ、ＬＯＢ、１０Ｃの各々は、シングル
・ユーザー・システムでも又マルチ・ユーザー・システ
ムでもよく、ネ・ントワーク３を用いて遠隔のノードに
位置するファイルにアクセスする能力を有している。例
えば、ローカル・ノードＡの処理システムＩＯＡは、各
々遠隔ノードＢ、Ｃにあるファイル５Ｂ、５Ｃにアクセ
スする事ができる。

本明細書において、用語「サーバー」は、ファイルが永
久的に保持できる形で記憶されている処理システムを示
すために使われ、用語「クライエント」は、そのファイ
ルにアクセスするプロセスを有する他の処理システムを
意味するために使われる。しかしながら、用語「サーバ
ー」は、あるローカル・エリア・ネットワーク・システ
ムで使われているような専用のサーバーを意味するもの
ではない。本発明が実施される分散サービス・システム
は、システム中の異なったノードで種々のアプリケーシ
ョンが走行し、それらがシステム中のどこに位置するフ
ァイルにもアクセスし得る真の分散システムである。

上述のように、以下説明する発明は、通信ネットワーク
中の分散データ処理システムに関するものである。この
環境において、ネットワーク中のノードの各処理装置は
、ファイルがとのノードにあっても、ネットワーク中の
全てのファイルにアクセスする事ができる。

分散データ処理システムを支援する他の方式も知られて
いる。例えば、ＩＢＭのＡＩＸオペレーティング・シス
テムに関する分散サービスは、１９８７年２月１３日に
出願された米国特許出願筒］４８９７号に開示されてい
る。さらに、サン・マイクロシステムズはネットワーク
・ファイル・システム（ＮＦＳ）をリリースし、ベル研
究所は、す′モート・ファイル・システム（ＲＦＳ）を
開発している。サン・マイクロシステムズのＮＦＳは、
Ｓ、Ｒ，Ｋｌｅｉｍａｎ、　　”Ｖｎｏｄｅｓ：　Ａｎ
　Ａｒｃｈｉｔｅｃｔｕｒｅ　ｆｏｒＭｕｌｔｉｐｌｅ
　Ｆｉｌｅ　５ｙｓｔｅＩＩＩＴｙｐｅｓ　　ｉｎ　Ｓ
ｕｎ　ＵＮＩＸ”。

−２４７；　　Ｒｕ５ｓｅｌ　Ｓａｎｄｂｅｒｇ　ｅｔ
　ａｌ、＋　　”Ｄｅｓｉｇｎ　ａｎｄＩｍｐｌｅｍｅ
ｎＬａｔｉｏｎ　　ｏｆ　　Ｌｈｅ　　Ｓｕｎ　　Ｎｅ
ｔｗｏｒｋ　　Ｆｉｌｅ−ｓｙｓＬｅｍｓ、　　　Ｃｏ
ｎｆｅｒｅｎｃｅ　　Ｐｒｏｃｅｅｄｉｎｇｓ、　　　
ＵＳＥＮＩＸ１９８５、　　ｐｐ、　　１１９　−　１
３０　　；　　Ｄａｎ　Ｗａｌｓｈ　　ａｔ　ａｌ、。

＋Ｏｖｅｒｖｉｅｗ　ｏｒ　ｔ、ｈｅ　Ｓｕｎ　Ｎｅｔ
ｗｏｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍｓ　。

ｐｐ、　　１１７−１２４　；　ＪｏＭｅｉ　Ｃｈａｎ
ｇ、　　”５ｔａｔｕｓ　Ｍｏｎ１ｔｏｒＰｒｏｖｉｄ
ｅｓ　　Ｎｅｔｗｏｒｋ　Ｌｏｃｋｉｎｇ　５ｅｒｖｉ
ｃｅ　　ｆｏｒ　　ＮＦＳ”＋ＪｏＭｅｉ　Ｃｈａｎｇ
　、　”５ｕｎＮｅｔ”、　ｐｐ、　７１−７５　；及
びＢｒａｄｌｅｙ　　Ｔａｙｌｏｒ、　　’″５ｅｃｕ
ｒｅ　　Ｎｅｔｗｏｒｋｉｎｇ　　ｉｎ　　ｔｈｅＳｕ
ｎ　Ｅｎｖｉｒｏｎｍｅｎｔ”、　ｐｐ、　２８−３６
を含む一連の刊行物に記載されている。ＡＴＴのＲＦＳ
は、Ａｎｄｒｅｗ　Ｐ、　Ｒｉｒｋｉｎ　ｅｔ　ａｌ、
、　−ＲＦＳ　ＡｒｃｈｉｔｅｃｔｕｒａｌＯｖｅｒｖ
ｉｅｗ　、　　ＵＳＥＮＩＸ　Ｇｏｎｒｅｒｅｎｃｅ　
Ｐｒｏｃｅｅｄｉｎｇ。

Ａｔ１ａｎｔａ、　Ｇｅｏｒｇｉａ　（Ｊｕｎｅ　１９
６８）＋　ｐｐ、　１−１２　：Ｒｉｃｈａｒｄ　Ｈａ
ｍｉｌｔｏｎ　ｅｔ　ａｌ、、　”Ａｎ　Ａｄｍｉｎｉ
ｓｔｒａｔｏｒ’ｓＶｉｅｗ　ｏｆ　Ｒｅｍｏｔｅ　Ｆ
ｉｌｅ　Ｓｈａｒｉｎｇ　＋　ｐｐ、　１−９　；　Ｔ
ｏｍ）１ｏｕｇｈｔｏｎ　ｅｔ　ａｌ、’、　−Ｆｉｌ
ｅ　５ｙｓｔｅ＋＋＋ｓ　５ｗ１ｔｃｈ”、　ｐｐ。

１−２；及びＤａｖｉｄ　Ｊ、　０１ａｎｄｅｒ　ｅｔ
　ａｌ−＋　”ＡＦｒａｍｅｗｏｒｋ　ｆｏｒ　Ｎｅｔ
ｗｏｒｋｉｎｇ　ｉｎ　Ｓｙｓｔｅｍ　Ｖ−ｒ　ｐｐ、
　１−８を含む一連の刊行物に記載されている。

本発明が実施される分散サービス・システムの１つの特
徴であって、サン・マインロシステムズのＮＦＳと異な
る点は、例えば、サンの方式が基本的に状態非保存の（
ｓｔａｔｅｌｅｓｓ）サーバーを設計しようとした事で
ある。これは、サーバーがクライエント・ノードに関す
る情報を記憶しない事を意味している。情報としては、
例えば、どのクライエント・ノードがサーバー・ファイ
ルをオーブンしているか、又はクライエント・ノードの
プロセスがファイルを読取り専用モード又は読み書きモ
ードのどちらでオープンしているかといった事である。

そのような実施形態はサーバーの設計を単純化する。と
いうのは、クライエントがサーバーの資源に対する要求
を解放しようとしている事をサーバーに適切に伝える事
なしにクライエントが故障したり又はオフライン状態に
なったりした時に生じるエラー回復状況を、サーバーが
処理する必要がないからである。

本発明が実施される分散サービス・システムの設計では
、完全に異なった方式が取られた。より具体的には、そ
の分散サービス・システムは「状態保存式の（ｓｔａｔ
ｅｒｕｌ）実現」として特徴付けられる。ここで述べる
ような「状態保存式」サーバーは、そのファイルを誰が
使用しているか、及びファイルがどのように使用されて
いるかについての情報を保持する。従って、サーバーは
、クライエントに関する蓄積された状態情報を廃棄でき
るように、クライエントとの接触の喪失を検出する何ら
かの方法を有していなければならない。ここで述べるキ
ャッシュ管理方式は、サーバーがそのような状態情報を
保持しなければ実現できない。

遠隔ノードをアクセスする時に出会う問題は、先ず、単
独で用いられるシステムがどのようにファイルにアクセ
スするかを調べる事によって良く理解できる。第２図に
示すノード１０のような単独のシステムにおいて、ワー
クステーション中のハード・ファイル又はディスク等の
永久的記憶装置２とユーザーのアドレス空間１４との間
で転送されるデータをバッファするために、オペレーテ
ィング°システムｌｌ中のローカル・バッファ１２が使
用される。オペレーティング・システム１１中のローカ
ル・バッファ１２は、ローカル・キャッシュ又はカーネ
ル・バッファとも呼ばれる。

単独のシステムでは、カーネル・バッファ１２はブロッ
ク１５に分割されている。これは、デバイス番号、及び
デバイス内の論理ブロック番号により識別されている。

読取りシステム・コール１６が発行される時、それは第
３図のステップ１０１に示すようにファイル５のファイ
ル記述子及びファイル５内のバイト範囲と共に発行され
る。オペレーティング・システム１１は、この情報を受
取り、第３図のステップ１０２に示すようにそれをデバ
イス番号及びデバイス中の論理ブロック番号に変換する
。もしブロックがキャッシュ中にあれば（ステップ１０
３）、データはｉｓキャッシュから得られる（ステップ
１０５）。キャッシュが、探しているブロックを保持し
ていない場合（ステップ１０３）、データはキャッシュ
中に読み込まれ（ステップ１０４）、その後キャッシュ
からデータが取得される（ステップ１０５）。

ディスク２から読取られたデータは、キャッシュ・ブロ
ック１５が他の目的のために必要になるまで、キャッシ
ュ・ブロック中に保持される。従って、処理システム１
０上で走行しているアプリケーション４からの連続した
読取り要求が、以前に読取ったのと同じデータに関する
場合は、ディスク２ではなくキャッシュ１２にアクセス
が行なわれる。キャッシュからの読取りは、ディスクか
らの読取りよりも通かに時間を要しない。

同様に、アプリケーション４から書込まれたデータは、
即座にディスク２上には保存されず、キャッシュ１２に
書込まれる。これは、他の書込動作が同じブロックに対
して行なわれる場合にディスクのアクセスを節約する。

キャッシュ１２中の変更されたデータ・ブロックは、周
期的にディスク２に保存される。

ＡＩＸオペレーティング・システムを用いる単独のシス
テムでのキャッシュの使用は、連続した読取りと書込み
に関してディスクのアクセスが不用になるので、システ
ムの全体的性能を改善する。

全体的性能の改善は、永久的記憶装置のアクセスがキャ
ッシュのアクセスよりも低速で且つより高価な事による
。

上述のように、オペレーティング・システム中のローカ
ル・バッファは、単独のシステムでのファイルへのアク
セスの性能を改善するために使われる。これらローカル
・バッファは、高速メモリ中に保持されるが、ファイル
は通常、より低速のディスク・ドライブ等の永久的記憶
装置中に保持される。より大きなバッファ・キャッシュ
はデータ処理システムの性能を増強できる。これは、キ
ャッシュがシステムのファイルに属するデータをより多
く保持する事ができ、従って低速のディスク・ドライブ
を使用する必要性を減少させるからである。しかしシス
テムの物理的な高速メモリは、限定されたサイズしか持
たない。オペレーティング・システムのカーネル・バッ
ファのために物理的メモリの一定部分を区分して使用す
る代りに、システムのディスク・ファイルへのアクセス
を高速化するために、仮想記憶技術を使用できる。この
仮想記憶技術では、ディスクのブロックの固定したキャ
ッシュは存在しない。その代りに、データは、物理的メ
モリではなく仮想メモリ中にキャッシュされる。

仮想メモリは、利用可能な物理的メモリよりも大きなメ
モリ空間を提供する。この仮想メモリ空間は、・複数ペ
ージに分割され、あたかも仮想メモリ空間が真の物理的
メモリであるかのようにプログラムによって使用される
。システムの仮想メモリのページは、現実の物理的メモ
リのフレーム、ディスクのブロック、のいずれが、又は
その両方に存在している。仮想メモリ・ページが物理的
フレーム中に存在しない時は、そのページを使用しよう
とする試みは、ページ・フォールトとして知られる例外
条件を生じさせる。そのようなページを使用しようとす
るプログラムは、ページ・フォールトを生成し、−時的
に停止させられる。その間に、仮想メモリのページが、
現在それが存在しているディスク・ブロックから検索さ
れ、物理的メモリ・フレームにコピーされる。仮想メモ
リ・ページが物理的フレームに割当てられた後、元のフ
ォールトを起こしたプログラムは継続する事を許され、
その仮想メモリ・ページ中のデータが利用可能である事
を見出すであろう。

仮想メモリによって提供される柔軟性を利用する１つの
方法は、プロセスがファイルをその仮想アドレス空間に
マツプ（写像）する事を可能にする事である。このよう
にして、プロセスは、読取り又は書込みのシステム・コ
ールを実行する事なく、ファイルの内容にアクセスする
事ができる。ファイルの読取り及び書込みが実行される
が、それは、ファイルがマツプされたアドレス空間内の
アドレスに対して実行されるプロセスのロード及びスト
ア（記憶）操作に応答して、仮想メモリ・マネジャに止
り実行される。例えば、１００バイトの短いファイルが
、４８００〜４８９９のアドレスの範囲にマツプされた
とする。プロセスが記憶位置４８０５から１バイトをロ
ードする時、プロセスはそのファイル内のオフセット５
のバイトを得るであろう。プロセスが記憶位置４８００
にストアを行なう時、プロセスはオフセット０の、即ち
ファイルの最初のバイトの内容を変更するであろう。

この事は、プロセスが、読取り又は書込みのシステム−
コールを行なう事なく、ファイルの内容にアクセスしそ
れを変更する事を可能にする。

第２Ｂ図に示すように、マツプされたファイル９２を含
むメモリ・セグメント９１に対するストアは、ファイル
９２を拡張する可能性があるが、ファイル・システム論
理９３は各ストア操作毎には呼出されない。従って、も
しアプリケーション９４がファイルをマツプし、ストア
操作によりファイルを拡張する場合、ｉノード・データ
構造９５の中のファイル・サイズ属性は同期して更新さ
れる事はない。任意の特定の瞬間には、ファイル・サイ
ズについてのファイル・システムの意見（ｉノード中に
記憶されたサイズ）は、最も最近の仮想メモリの記憶内
容と一致してはいない。ファイル９２に関する情報を含
むデータ構造であるｉノード９５は、５ｙｎｃ％　ｆｓ
ｙ’ｎｃｓ　　ｃｌｏｓｅ等のシステム・コールにより
、またオペレーティング・システム９６により実行され
る周期的な５ｙｎｃ動作により最新状態にされる。ファ
イルが従来のシステム・コール（例えば、書込み）によ
り変更される時、ファイル・システム論理９３が起動さ
れ、それはマツプされたファイル記憶を使用して、ファ
イルのデータを更新する。ファイル−システム論理９３
は、システム・コールのパラメータによって、ファイル
に対して何が行なわれているかを知り、同期的にｉノー
ド・データ構造９５中のファイル・サイズを更新する。

５ｔａｔシステム・コールは、現在のｉノードのファイ
ル・サイズ値を返すが、それは仮想メモリ・マネジャ９
７には照会しない。その結果、もしファイル９２が専ら
システム・コールによってのみ操作されていれば、ｉノ
ード・データ構造中に見出されるファイル・サイズ、及
びｓ　ｔａｔよって返されるファイル・サイズの値は、
常に最新のものである。

しかし、もしファイルがマツプされた記憶域により操作
されていれば、５ｔａｔにより返されるファイル・サイ
ズは、最も最近の記憶の結果を反映していないがもじれ
ない。（システム・コールではなく）マツプ式アクセス
を使用するアプリケーション９４は、５ｔａｔが最も最
近の変更を反映している事を保証したいならば、ｆｓｙ
ｎｃシステム・コールを発行する事ができる。もしアプ
リケーションが、（システム・コールではなく）ストア
操作を用いてファイル９２を拡張したならば、仮想メモ
リ・マネジャ９７はどのページがファイルの「最右端」
のページかを知っているが、そのページ内のとのバイト
がファイルの最後のバイトかは知らない。しかし、シス
テム・コールが使用されると、ファイル・システムは、
バイトの粒状性（ｇｒａｎｕｌａｒｉｔｙ）を用いて、
ファイル・サイズを知る。

第５図に示すような、分散環境において、ローカル・ノ
ードＣにある処理システムＩＯＣがノードＡからファイ
ル５Ａを読取る事ができる２つの方法がある。１つの方
法では、処理システム１゜Ｃがファイル５Ａ全体をコピ
ーし、あたかもそれがノードＣに存在するローカル・フ
ァイル５ｃであるかのように読取りを行なう。この方法
のファイル読取りは、もしファイル５Ａがファイル５Ｃ
としてノードＣにコピーされた後で他のノードＡの他の
処理システムＩＯＡがファイル５Ａを変更する場合に、
問題を生じる。その場合、処理システムＩＯＣは、ファ
イル５Ａに対するこれら最新の変更にアクセスしないで
あろう。

ノードＡのファイル５Ａに処理システムＩＯＣがアクセ
スする他の方法は、ノードＣの処理システムが要求する
時に、１ブロツク、例えばＮ１を読取る事である。この
方法に伴う問題は、あらゆる読取りが、ネットワーク通
信リンク３を経由して、ファイルが存在しているノード
Ａに行かなければならない事である。各連続した読取り
毎にデータを送信するのは多大の時間を要する。

ネットワークを介してファイルにアクセスする事は、上
述のように２つの競合する問題を生じる。

１つの問題は、連続した読取りと書込みのためにネット
ワークを介してデータを転送するのに必要な時間に関係
している。一方、もしネットワーク・トラフィックを減
少させるためにファイルのデータがノードに記憶される
ならば、ファイルの整合性が失われる可能性がある。例
えば、もし幾つかのノードの１つがファイルに書込みも
行なうと、そのファイルにアクセスしている他のノード
は、ちょうど書込まれた最新の更新されたデータにはア
クセスしない可能性がある。従って、ノードが正しくな
く且つ古くなったファイルにアクセスする可能性がある
という意味で、ファイルの整合性が失われる。

分散環境中のファイルに篤するデータを管理する困難性
に加えて、分散処理環境中でアクセスされるファイルの
属性を管理するという間層が存在する。ファイルは、頻
繁に変化する３つの重要な属性を有している。それは、
ファイル・サイズ、最後の変更の時刻、そしてファイル
への最後のアクセスの時刻である。プロセスがファイル
の終端にデータを付は加える毎に、最後の変更の時刻及
び最後のアクセスの時刻ととも゛にファイル・サイズが
変化する。またファイルがプロセスにより読取られる毎
に、最後のアクセスの時刻が変化する。

この情報を正確に保持する１つの方法は、ファイル・サ
ーバーに情報を保持する事である。クライエントにより
ファイルがアクセスされる毎に又はファイル・サイズが
変更される毎に、クライエントは、サーバーにメツセー
ジを送って、サーバーに変更を通知する。クライエント
により属性が要求される毎に、クライエントはサーバー
に属性の値を要求するメツセージを送る。この解決方法
は正しいファイル属性を維持するが、クライエントでフ
ァイルが読取り又は書込みされる毎にサーバーとの間で
メツセージの送受信が必要なのでコストが余りに高くな
る。

一方、もし属性がクライエントの計算機に保持されるな
らば、分散環境中の他のクライエント及びサーバーは正
しい属性値を有しないであろう。

複数のクライエントが同時にファイルにアクセスする事
があるので、矛盾のある属性値が同時に種々のクライエ
ントに存在する事もありうる。

プロセスがファイルをその仮想アドレス空間にマツプす
る事を許す事により、さらに付加的な複雑さが生じる。

これが行なわれると、プロセスは、読取り又は書込みの
等のシステム・コールを使う事なく、ファイルの内容を
操作し、おそらくそのサイズ及び最後のアクセス又は変
更の時刻を変更する事が可能である。このアクセスはロ
ード及びストア命令を通じて起きる。この種の状況では
、オペレーティング・システムは、システム−コールを
用いた場合のようには、最後のアクセス時刻及び他のフ
ァイル属性を追跡する機会を持たない。

同様に、プロセスが遠隔ファイルを仮想アドレス空間に
マツプする事を許す分散環境でも、もし有用なファイル
属性が保持されるべきであれば、これらの複雑さが存在
する。

Ｃ０発明が解決しようとする課題 従って、本発明の目的は、サイズ、最後の変更の時刻、
及び最後のアクセスの時刻等のファイル属性が分散処理
環境中の全てのクライエントにおいて正確であり且つ利
用可能であるように、それらのファイル属性を維持する
事である。

本発明の他の目的は、不当なオーバーヘッド、性能コス
ト及びネットワーク・トラフイ・ンクなしにファイル属
性を正確に維持する事である。

０２課題を解決するための手段 本発明のシステム及び方法は、ファイルの属性が関係プ
ロセスの全てに対して効率的且つ正確に分散されるよう
な形で、分散環境中のプロセスが、読取り及び書込み等
のシステム・コール、又はファイルをそれ自身のアドレ
ス空間にマツプする機構のいずれを通じてもファイルに
アクセスする事を可能にするプロトコルを提供する。

ファイル・サイズ属性、変更時刻属性、及び最終アクセ
ス時刻属性等のファイルの属性は、各々別個に、そして
分散環境中の他の属性の各々とは独立に管理される。

ファイル・サイズ属性は、次のように管理される。読取
り又は書込みのシステム・コールを実行するクライエン
トは、ファイルの読取りトークンの１つ又はファイルの
書込みトークンを要求する事により、ファイルのサーバ
ーからそのようにする許可を取得する。ファイルに対す
る操作の実行の許可を与える事に加えて、トークンはフ
ァイルの現在のサイズも含んでいる。−時にただ１つの
クライエントだけしか書込みトークンを所有できないの
で、書込みトークンを有しているクライエントのプロセ
スだけがそのファイルに書込みを行なう事ができ、ファ
イル・サイズは書込みトークン中に保持できる。書込み
システム・コールによるファイル・サイズの変更は、書
込みトークン中に保持されているサイズを更新する事に
より反映できる。

ファイルをそれ自身の仮想アドレス空間にマツプする事
を通じてファイルにアクセスするプロセスは、書込みト
ークンを取得する事なくファイルを拡張しサイズを変更
する事ができる。ファイル・サイズに対するこれらの変
更は、そのファイルに関するサーバーのサイズ情報が時
代遅れにならないように周期的にサーバーに伝達される
。ネットワーク中のどこかのプロセスがファイル・サイ
ズに興味を持つと、そのプロセスは、サーバーにｇｅｔ
　　ａｔｔｒメツセージを送る。次に、サーバーは、書
込みトークンを所有しているノードに質関し、それと、
（ファイルをマツピングする事によりファイルを拡張し
たプロセスを有しているクライエントから）サーバーが
得た情報とを組合せる。サーバーは、ファイルの現在の
サイズに関する最良の利用可能な情報を反映するファイ
ル・サイズを、要求を行なっているクライエントに返す
。

変更時刻とアクセス時刻の保持は、既に述べたファイル
・サイズ属性の保持と同様に行われる。

これらの属性は読取り及び書込みトークン中に保持され
る。

変更時刻属性に関して、書込みトークンは、次のルール
に従って変更時刻属性を管理するために使われる。サー
バーは、ファイルに関する変更カウントを保持する。ク
ライエントが書込みトークンを取得する時、それは変更
カウントも取得する。

クライエントがファイルを変更する時、クライエントは
変更カウントを力計数する。ファイルが変更されたかど
うかをサーバーが判定したい時、サーバーは、特別の取
消トークン・メツセージを送る。これはクライエントに
、変更カウントをサーバーに送り返させる。サーバーは
、クライエントからの変更カウント（これは力計数され
ているかもしれない）をサーバーの変更カウントと比較
し、クライエントが書込みトークンを有している間にフ
ァイルが変更されたか否かを判定する。もしサーバーが
、ファイルが変更されたと判定すると、サーバーは、変
更時刻を現在の時刻に設定する。

最後にファイルがアクセスされた時をクライエントが知
る事はより重要ではない。多くのクライエントが読取り
トークンを有しているかもしれないので、読取りトーク
ンを有している各クライエントに最後のアクセスの時刻
を照会するのは余りに煩雑である。その代りに、要求を
行っているクライエントは、ただ、サーバーに、どこか
のクライエントによる最後のアクセスの時刻だけを照会
する。読取りトークンを有しているクライエントは、フ
ァイルへのアクセスについて定期的にサーバーに知らせ
るように要求されているので、サーバーは最後のアクセ
スの時刻を決定できる。

Ｅ、実施例 第４Ａ図〜第４１図を参照すると、ここで使用されるノ
ード間メツセージが記載されている。

第４Ａ図は、ファイルに関するサーバーの知識をクライ
エントのものと同期させるために使われるｆ　　５ｙｎ
ｃメツセージを示している。クライエントからのｆ　　
５ｙｎｃメツセージに応答して、サーバーはｆ　　５ｙ
ｎｃ動作を実行する。ｆｓｙｎｃ動作は、変更されてい
るがまだ書込まれていない全てのデータを、サーバーが
、サーバーのディスクに書込むようにさせる。そうする
ために、サーバーは、未解決のファイル・トークンを取
消し、クライエントの計算機上のファイルに付随するデ
ータ・バイトを取消し、次に変更されたデータ・バイト
をディスクに書込ませるサーバーでのローカルｆ　　５
ｙｎｃ動作を実行する。もしクライエントが書込みのた
めにファイルを以前にオーブンして、まだクローズして
いなければ、サーバーはだだｆ　　５ｙｎｃ動作を実行
するだけである。

ｏｐコード４２１．４２３は、どの動作が実行されるか
を示す。Ｏｐコードの値は、各個々の動作に関するメツ
セージとは独立である。ファイル・ハンドル４２２は、
サーバー計算機に存在するファイルを一意に識別する値
である。リターン・コード４２４は、要求された動作の
成功又は失敗を示す値、である。

第４Ｂ図は、ファイルの属性を得るｇｅｔ　　ａｔｔｒ
メツセージ４３０を示す。ファイル属性４３５は、アク
セス時刻４３６、変更時刻４３７、及びファイル・サイ
ズ４３８等のファイルに関する情報を含んでいる。

第４Ｃ図は、ファイルからデータ・バイトを要求するｇ
ｅｔ　　ｂｙｔｅｓメツセージ４４０を示している。オ
フセット４４１は、要求されたデータの開始点を示すフ
ァイルのオフセットである。

長さ４４２は、・要求されたバイトの数である。読取り
／書込みフラグ４４３は、クライエントが、データの読
取り専用のコピーを要求しているか又は書込み可能のコ
ピーを要求しているかを示すために使われる。Ｒ／Ｗフ
ラグの許された値は、もしクライエントがバイト範囲を
読取るだけの場合は０ｘＯＯＯＯであり、もしクライエ
ントがバイトを変更しうる場合は０ｘＯＯＯ１である。

もしクライエント・ノードが互換モードでファイルを以
前にオーブンしていて、まだクローズしていなければ、
サーバーはｇｅｔ　　ｂｙｔｅｓ動作だけを実行する。

もしＲ／Ｗフラグ４４３が読取り専用であれば、クライ
エントはファイルを読取りのためにオーブンさせたはず
である。もしＲ／Ｗフラグ４４３が読み書きであれば、
クライエントはファイルを書込みのためにオーブンさせ
たはずである。

ｇｅｔ　　ｂｙｔｅｓメツセージ４４０の応答において
、ＮＺオフセット４４４は、初期（ｎａｓｃｅｎｔ）ゼ
ロが存在するバイトが要求されているファイル内のオフ
セットである（初期ゼロは、本発明の関連出願に説明さ
れている）。このフィールドは、フィールドＮＺ長さが
ゼロよりも大きい時にのみ意味を持つ。フィールドＮＺ
長さ４４５は、初期ゼロのバイト数であり、これはＮＺ
オフセット４４４から始まる。サーバーは、要求者に返
すためにＮＺオフセットを選択する。サーバーは、常に
初期ゼロの処置を行なわないように選択しても良く、こ
のフィールドにゼロを返す事によってこの事を示す。長
さ４４６は、返されるデータの長さである。データ４４
７は、要求された実際のデータ・バイトである。

第４Ｄ図は、サーバーからトークンを要求するためにク
ライエントにより使用されるｇｅｔ　　ｔｋｎメツセー
ジ４５０を示している。トークン型４５１は、どの種類
のトークンが要求されているかを指定する。もし読取り
専用トークンが要求されているならば、許された値は０
ｘＯＯＯ１であり、もし読取り／書込みトークンが要求
されているならば、０ｘＯＯ０２である。もしクライエ
ント・ノードが以前にオーブンされていて且つまだクロ
ーズされていす、ファイルが互換モードであれば、サー
バーは単にｇｅｔ　　ｔｋｎ動作しか実行しない。ファ
イル・サイズ４５２は、ファイルのサイズである。変更
カウント４５３は、ファイルの変更を反映する、サーバ
ーによって保持されている値である。アクセス・カウン
ト４５４は、ファイルへのアクセスを反映する、サーバ
ーによって保持されている値である。

第４Ｅ図は、ｐｕｔ　　ｂｙｔｅｓメツセージ４６０を
示す。クライエントは、ｐｕｔ　　ｂｙｔｅＳメツセー
ジ４６０を用いてサーバーに変更データを返す。もしク
ライエントが以前にオープンを行っていて且つまだクロ
ーズを行っていす、ファイルが書込み用であれば、サー
バーは単にｐｕｔｂｙｔｅｓ動作だけを実行する。オフ
セット４６１は、長さ４６２のデータ・バイト４６３が
置かれるべきファイル内のオフセットである。

第４Ｆ図は、ｒｅｖｏｋｅ　　ｂｙｔｅｓメツセージ４
７０を示す。このメツセージは、ｇｅ＝ｔ−ｂｙｔｅｓ
メツセージ４４０に対する応答の中でクライエントに以
前与えられたバイトを取消すためにファイルのサーバー
からクライエントに送られる。クライエントは、オフセ
ット４７１及び長さ４７２によって示されるバイト範囲
に関して、それが全てのクリーンなキャッシュされたデ
ータ及び初期ゼロを廃棄し、全ての汚れたデータをサー
バーに書込み応答を受取るまでは、応答を送らない。ク
ライエントが応答を送る時、それは、取消されたバイト
範囲に関するキャッシュされたデータを全く有していな
いはずである。このメツセージは、取消し範囲内に入る
、以前に返された初期ゼロをクライエントが使用する権
利を取消す。

ｒｅｖｏｋｅ　　ｂｙｔｅｓが処理される時に未解決で
あったｇｅｔ　　ｂｙｔｅｓ要求により返された取消さ
れたバイト範囲内のどのデータ又は初期ゼロも、それら
が到着する時に取消されなければならない。クライエン
トは、要求されたよりも大きなバイト範囲を取消す事を
選択しても良く、又要求された範囲よりも大きな範囲中
に取消すものが存在しない事を判定できても良い。その
ような場合、応答オフセット４７３及び応答長さ４７４
が、クライエントがキャッシュされたページを持たない
範囲を示す。応答オフセット４７３及び応答長さ４７４
は、少なくとも、オフセット４７１及び長さ４７２によ
って示された範囲を含まなければならない。

第４Ｇ図は、ｒｅｖｏｋｅ　　ｔｋｎメツセージ４８０
を示す。このメツセージは、ｇｅｔ　　ｔ。

ｋｅｎメツセージ４５０に応答してクライエントが受取
ったトークンを取消すために、サーバーがらクライエン
トに送られる。残留トークン型４８１は、クライエント
に残されるべきトークンの種類を特定する。許される値
は、クライエントが読取り専用トークンを保持する場合
、ｒｅａｄ　　ｔｋｎ　　０ｘＯＯＯ１であり、クライ
エントが読取り／書込みトークンを保持する場合、ｗｒ
ｉｔｅｔｋｎ　　０ｘＯＯ０２であり、クライエントが
何のトークンも保持しない場合は、ｎｏ　　ｔｋｎＯｘ
ＯＯＯである。

ファイル・サイズ４８２は、データの変更後にクライエ
ントから見たファイルのサイズである。

システムの状態に関するサーバーとクライエントとの間
の混乱を避けるために、次のルールに従わなければなら
ない。クライエントにおけるファイルに関するｒｅｖｏ
ｋｅ　　ｔｋｎ４８０の処理は、そのファイルに関する
未解決のｇｅｔ　　ｔｋｎ４５０に対する応答が処理さ
れるまで、遅延される。

第４Ｈ図は、５ａｎｅ　　ａｔｔｒメツセージ４９０を
示す。このメツセージは、ファイルの属性に対して同期
化動作を実行する。トークン型４９１は、クライエント
がどの種類のトークンを保持しているかを特定する。有
効な値は次の通りである。

クライエントが読取り専用トークンを保持するならば、
ｒｅａｄ　　ｔｋｎ　　０ｘＯＯＯ１、クライエントが
読取り／書込みトークンを保持するならば、ｗｒｉｔｅ
　　ｔｋｎ　　０ｘＯＯ０２である。

要求ファイル・サイズ４９３は、クライエントにおける
ファイル・サイズである。応答ファイル・サイズ４９４
は、サーバーにおけるファイル・サイズである。応答変
更カウント４９５は、サーバーに記録された変更を反映
する。応答アクセス・カウント４９６は、サーバーに記
録されたアクセスを反映している。システムの状態に関
するサーバーとクライエントとの間の混乱を避けるため
に、次のルールに従わなければならない。ｇｅｔ　　ｔ
ｋ、ｎ動作及び５ｙｎｃ　　ａｔｔｒ動作は、クライエ
ントにおいて直列化される。特定のファイルに関するｇ
ｅｔ　　ｔｋｎＷ求は、そのファイルに関する未解決の
５ｙｎｃ　　ａｔｔｒが存在する間は、発行できない。

第４工図は、クライエントがサーバーにクローズ動作を
知らせるために使用されるｃｌｏｓｅメツセージ４１０
を示す。変更カウント４１１は、クライエントにおける
変更を反映する値である。

アクセス・カウント４１２は、クライエントでのアクセ
スを反映する値である。

第１図に示すような、本発明の良好な実施例では、第２
Ａ図に示すような従来のカーネル・バッファ１２を使う
代りに、キャッシュされたファイル・データを管理する
ために仮想メモリ・マネジャ３３が使われる。さらに、
本発明の良好な実施例は、ファイルがアプリケーション
３４の仮想記憶セグメント３５にマツプされる事を可能
にする。

しかし、この良好な実施例は、ファイル・システム論理
３６が仮想メモリ・マネジャ論理３３と過度に干渉する
のを避けている。５ｙｎｃ、ｆｓｙｎｃ、ファイル・シ
ステムの定期的な５ｙｎＣ（これらはＡＩＸオペレーテ
ィング・システムのシステム・コールであり、’　ＡＩ
Ｘ　ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ　Ｔｅｃｈｎｉｃ
ａｌ　Ｒｅｒｅｒｅｎｃｅ」に記載されているが、ディ
スク又は永久的記憶装置上に存在すべきメモリ中の全て
の情報を書き出させる他のオペレーティング・システム
のシステム・コールにも適用可能である）、及びファイ
ルの最後のクローズの間に、ｉノード・データ構造２６
中のファイル・サイズが次のルールに従って、セットさ
れる。

もしｉノードのファイル・サイズが最右端のページに含
まれているならば、ｉノードのファイル・サイズはその
ままにされる。そうでなければ、ｉノードのファイル・
サイズは最右端のページの終端にセットされる。

ｉノードのアクセス時刻及び変更時刻の属性は、同様に
、最も最近の仮想記憶の活動にルーズに結合している。

第１図及び第６Ａ図を参照すると、クライエント３０は
、ファイルの終端を越えて記憶動作を行なう事によりフ
ァイル２５を拡張する事ができる。

記憶動作を行なう記憶位置にファイル中のページが存在
しない事がクライエントで起きる時、クライエントはサ
ーバーにｇｅｔ　　ｂｙｔｅｓ要求４４０を発行する事
によってページに関するデータを得るように強制される
。ｇｅｔ　　ｂｙｔｅｓ要求４４０は、ページ中に挿入
されたデータ・ブロックを返し、記憶動作はそのページ
内容を対象とする。またクライエントは、ファイルの終
端を越えて空間を予約しているかもしれない。この予約
された空間への記憶動作は、サーバーにｇｅｔ−ｂｙｔ
ｅｓ要求が発行される必要がない。クライエントがｇｅ
ｔ　　’ｂｙｔｅｓ　４４０をファイルの終端で発行す
る時（ステップ６０１．６０２）、サーバーは、クライ
エントがファイルの終端を越えて空間を予約できる標識
４４４．４４５（第４ＣＩ！ｌ！り（ステップ６０３）
を返してもよい（ステップ６０４．６０５）。この予約
された空間は、関連出願に開示されているように、初期
ゼロと呼ばれる。クライエントがこれらの初期ゼロに記
憶動作を行なう時、ファイルのサイズが増加する（ステ
ップ６０６）。サーバー２０は、クライエントがｐｕｔ
　　ｂｙｔｅｓ　　４６０（第４Ｅ図）を発行してデー
タをサーバーに書き戻す（ステップ６１０．６１１）ま
で、ファイルの成長に気付かない。クライエントは、デ
ータを書き戻すように一方的に決定してもよく、又ｒｅ
ｖｏｋｅ　　ｂｙｔｅｓメツセージ４７０（第４Ｆ図）
により、そうする事を命令されてもよい。このメッセー
　ジは、他のプロセスが同しデータを要求する（ステッ
プ６０７）事が原因となって、サーバー２０からクライ
エント３０が受け取る（ステップ６０８．６０９）。こ
の他のプロセスは、ｒｅｖｏｋｅ　　ｂｙｔｅｓ要求４
７０に対する応答がサーバーに到着した（ステップ６１
４．６１５）後で、このデータを使用する事が許される
。ステップ６１４で、クライエント３０は、ステップ６
１２．６１３のｐｕｔ　　ｂｙｔｅｓの応答を受け取っ
た後に、ｒｅｖｏｋｅ−ｂｙｔｅｓ応答４７０を送信す
る。

第６Ｂ図を参照すると、クライエントが、ファイルの属
性を照会するために５ｔａｔ動作を実行する時、５ｔａ
ｔ動作は、ｇｅｔ　　ａｔｔｒ要求４３０がファイルの
サーバーに送られる原因になる。ｇｅｔ　　ａｔｔｒに
より返される構造体中の要素の１つは、ファイルのサイ
ズ４３６（第４Ｂ図）である。次のシナリオを考察する
。

１、クライエントＡが、ｇｅｔ　　ｂｙｔｅｓ応答４４
．０を受け取り、ファイル終端の初期ゼロに記憶動作を
行う（ステップ６１６．６１７．６１８）。クライエン
トは、サーバーに新しいファイル・データを送り返して
いない。

２、クライエントＢが、そのファイルに関するｇｅｔ　
　ａｔｔｒ　　４３０を発行する（ステップ６１９．６
２０）。

もし厳密な正確さが必要であれば、サーバーは、クライ
エントＢのｇｅｔ　　ａｔｔｒ　４３０に応答する（ス
テップ６２９，６３０）前に、ファイル終端の初期ゼロ
に記憶動作が行なわれたか否かを判定するためにクライ
エントＡにｒｅｖｏｋｅ−ｂｙｔｅｓ　４７０を発行し
なければならない（ステップ６２１．６２２）。ｇｅｔ
　　ａｔｔｒ　４３０中で返されるファイル・サイズ４
３６（第４Ｂ図）が、最も最近のクライエントの記憶動
作を正確に反映する事を要求すると、２重の性能上のペ
ナルティが課される。

１、ｇｅｔ　　ａｔｔｒは、ｒｅｖｏｋｅ　　ｂｙｔｅ
ｓ　４７０が発行され（ステップ６２１．６２２）、そ
して応答がなされる（ステップ６２７．６２８）まで、
ステップ６２９．６３０で応答が行なわれることはない
。

２、ｒｅｖｏｋｅ　　ｂｙｔｅｓに応答して、クライエ
ントは、サーバーに１以上のｐｕｔｂｙｔｅｓ　　４６
０を発行しくステップ６２３．６２４）、そしてその応
答を待機しくステップ６２５，６２６）なければならな
い。

この性能のペナルティを回避するために、且つ書込みの
ためにオーブンされているファイルのサイズは変化する
可能性が高いという事実を考慮して、プロトコルは、ｇ
ｅｔ　　ａｔｔｒ　４３０によって返されるファイル・
サイズ４３６が最も最近のクライエントの記憶動作を反
映している事は要求しない。サーバーは、ｇｅｔ　　ａ
ｔｔｒ　　４３０に応答する前にｒｅｖｏｋｅ　　ｂｙ
ｔｅｓ４７０を発行するように実現してもよいが、クラ
イエントはサーバーがそのようにする事に依存できない
。

クライエントに関する緩められたルールを考慮し、且つ
サーバーの実施形態のオプションを許容するために、プ
ロトコルは、ｇｅｔ　　ａｔｔｒ４３０によって返され
るファイル・サイズ４３６がサーバー・プロセスによる
最も最近の記憶動作を反映することを要求しない。そし
て、サーバーは、ｐｕｔ　　ｂｙｔｅｓ　　４６０によ
り送られたバイト、及び同様にローカル・プロセスによ
り書き込まれたバイトを取り扱う事が多いので、プロト
コルは、ｇｅｔ　　ａｔｔｒ　　４３０によって返され
るファイル・サイズ４３６が最も最適量は取ったｐｕｔ
　　ｂｙｔｅｓを反映する事を要求しない。

プロトコルは、以下の事を要求する。

１、クライエントは、変更された又は形成されたファイ
ル・データ（即ち、記憶が行われた初期ゼロ）を、ｐｕ
ｔ　　ｂｙｔｅｓ　　４６０を介して、周期的に送信す
る事が期待される。又、クライエントは、ファイルに関
する最後のクローズ・メツセージ４１０を送信する前に
、変更又は形成されたデータを送信する事が期待される
。

２、サーバーは、サーバー・プロセスによる最近の活動
を反映し、且つ最近受取ったｐｕｔ　　ｂｙｔｅｓメツ
セージ４６０を反映するように、ｉノード・データ構造
２６（第１図）中のファイル・サイズを周期的に更新す
る事が期待される。

３、ｆｓｙｎｃ要求を処理する一部として、サーバーは
、全てのクライエントからのデータを取消し、返された
データを反映するように、且つサーパー・プロセスによ
る以前の活動を反映するように、ｇｅｔ　　ａｔｔｒ　
　４３０により返されたファイル・サイズ４３６を更新
する事が期待される。

従って、クライエントの周期的な同期化動作の一部は、
サーバーに汚れたデータを書込む事であり、サーバーの
周期的な同期化動作の一部は、ローカルな変更及び受取
ったクライエントの変更をディスクに書込む事である。

ｆｓｙｎｃ又はファイルの最後のクローズ等の、何らか
の他の事象が起きなければ、クライエントの変更は、ク
ライエントの周期的な同期化がサーバーの周期的な同期
化に続くまで、ｇｅｔ　　ａｔｔｒ　　４３０により返
されるファイル・サイズ４３６中に示されない。

クライエントは、そのファイル・データ・キャッシュを
固定サイズのブロックの形に構成している事が多い。次
のシナリオを考察する。

１、クライエントがファイル終端部の初期ゼロ中に記憶
を行う。これは、ファイル・サイズを増加させる。

２、クライエントにおける周期的な同期化動作が、ｐｕ
ｔ　　ｂｙｔｅｓメツセージをサーバーに送らせる。

典型的なりライエンドの実施形態では、ｐｕｔｂｙｔｅ
ｓメツセージ４６０中でオフセット４６１と長さ４６２
により指定されたバイト範囲は、クライエント・ページ
と整合している。バイト範囲は、ファイル中の最後のバ
イトを含むが、多くの場合、この最後のバイトを越えて
延長している。

さらに、サーバーのページ・サイズは、クライエントの
それと一致しない事がある。従って、ｐｕｔ　　ｂｙｔ
ｅｓデータがサーバーに届いた時、それは、メツセージ
中で送られた最後のデータ・バイトを過ぎて延長してい
るサーバー・ページにおかれる可能性がある。このペー
ジ・サイズの量子化により、サーバーは、どのバイトが
ファイル終端かを正確に知る事は合理的には不可能であ
る。

それはただ、最後のバイトを含むページを知っているだ
けである。このため、プロトコルは、単に、サーバーが
ｉノード・データ構造２６中のファイル・サイズを周期
的に更新してそれがサーバーの最右端のページを含むよ
うにする事だけしが要求しない。ファイル中の最後のバ
イトは、ｐｕｔ−ｂｙｔｅｓ　　４６０を介して以前に
送られているかもしれず、又サーバー・プロセスにより
形成されているかもしれない。

上述のように、クライエントは、ｐｕｔ　　ｂｙｔｅｓ
メツセージをファイルのサーバーに送る事によってファ
イルのサイズを変更できる。クライエントは、ファイル
の書込みトークンを取得する事によってファイルのサイ
ズを変更する時に、より正確な制御を行う事ができる。

第６Ｃ図を参照すると、クライエントＡが、書込みトー
クンを要求するｇｅｔ　　ｔｋｎ４５０を送る時（ステ
ップ６３１．６３２）、応答（ステップ６３３．６・３
４）は、ファイルのサイズ４５２（第４Ｄ図）を伝達す
る。これは、ｇｅｔ　　ａｔｔｒ要求４３０中で返され
るのと同じサイズ値４３６である。クライエントがファ
イルの書込みトークンを保持している間、それはファイ
ルのサイズを変更しうる（ステップ６３５）。変更され
たサイズは、ｒｅｖｏｋｅ　　ｔｋｎメツセージ４８０
又は５ｙｎｃ　　ａｔｔｒメツセージ４９０に応答して
サーバーに返される。ファイル・サイズを支配するルー
ルは、次のように述べられる。

サーバーがｇｅｔ　　ａｔｔｒ要求４３０を受取る時（
ステップ６３６．６３７）、それは、もしファイルの書
込みトークンを保持しているクライエントが存在すれば
、そのクライエントにｒｅｖ。

ｋｅ　　ｔｋｎメツセージ４８０を送る（ステップ６３
８．６３９）。このｒｅｖｏｋｅ　　ｔｋｎメツセージ
４８０は、クライエントに、ファイルの現在のサイズを
、応答（ステップ６４０．６４１）中で返すように指令
する。しがし、これは、クライエントにトークンの所有
権を失なわせる事はない（即ち、それは非パージング取
消しとしてフラグされている）。返されたファイル・サ
イズは、ｉノード２６（第１図）中に置かれ（ステップ
６４２）、ｇｅｔ　　ａｔｔｒ応答で返される（ステッ
プ６４３．６４４）。

第６Ｄ図を参照すると、サーバーにおけるいくつかの動
作が、ファイルのｉノード中に記憶されたファイル・サ
イズを、仮想メモリ・マネジャによって保持されるファ
イルの最右端のページの位置と矛盾しないようにさせる
（ステップ６５６）。

もし結果的に得られたファイル終端が最右端のページ内
に入るならば、ファイル・サイズに矛盾はない。これら
の同期化事象は、下記の通りである。

１）サーバーが、ファイルの周期的な同期化を行う（ス
テップ６５１）。

２）サーバーが、ファイルの最後のクローズを行う（ス
テップ６５２）。

３）サーバーが、クライエントとサーバーとのファイル
に関する知識を同期化させる、ｆｓｙｎｃ等の、いくつ
かのメツセージの１つを受取る（ステップ６５３）。

４）サーバー・プロセスが、クライエントとサーバーと
のファイルに関する知識を同期化させる、ｆｓｙｎｃ等
の、いくつかの動作の１つをを行う（ステップ６５４）
。

もし上記同期化事象の１つが起き、そしてｉノードのフ
ァイル・サイズがサーバーのファイルの最右端のページ
内に含まれているか又はファイルの最右端のページの右
側にあれば（ステップ６５５）、ｉノード値はそのまま
残される（ステップ６５８）。もしそうでなければ、ｉ
ノードのサイズは、最右端のページの最後のバイトにフ
ァイル終端を置くように調整される（ステップ６５６）
。

クライエントは、まだサーバーに送られていない変更さ
れた被キャッシュ・ページ有している可能性がある。従
って、ｒｅｖｏｋｅ　　ｔｋｎメツセージ４８０（第４
Ｅ図）で返されたファイル・サイズは、サーバーの最右
端のページの右側にある可能性がある。

サーバーは、（クライエントの周期的同期化により発行
された）ｓｙｎｃ　　ａｔｔｒメツセージを受取る時（
ステップ６５３）、又はｒｅｖｏｋｅｔｋｎに対する応
答を受取る時（ステップ６５９）に、ｉノードのファイ
ル・サイズを更新する。

書込みトークンを有し且つファイルを変更するために書
込みを使用しているクライエントは、キャッシュ・オー
バーフローにより、ファイルの最右端のページを送信し
ている可能性がある。もしサーバーがこれを受取り、次
に周期的な同期化を行うと（ステップ６５１）、ステッ
プ６５５で決定されるようにこのページがファイル・サ
イズについてのサーバーの現在の記録よりも彼方のペー
ジである時は、それはファイル・サイズをこのページの
終りに移動する（ステップ６５６）。その後クライエン
トが、トークン取消し要求（ステップ６５９）、５ｙｎ
ｃ　　ａｔｔｒ又はｒｓｙｎｃ要求（ステップ６５３）
によりファイル・サイズを送信する時、ｉノードのファ
イル・サイズは、サーバーに知られている最右端のペー
ジ内にある事が見出されるかもしれず（ステップ６５５
）、従ってそのままにされる（ステップ６５８）。この
動作は、ファイル・サイズを、最右端のページの終りの
値から減少させるかもしれない。

良好な実施例では、従来の書込みシステム・コールを用
いてファイルに対して操作を行っているクライエント・
プロセスは、書込みトークンを取得し書込みの進行とと
もにファイル・サイズを更新する事が期待される。もし
そのようにしているならば、ｇｅｔ　　ａｔｔｒにより
返されるファイル・サイズは常に最新のものになってい
る。クライエントは、ファイルの書込みトークンを取得
する事なく、単にｇｅｔ　　ｂｙｔｅｓ及びｐｕｔ−ｂ
ｙｔｅｓを発行する事によって、マツプされたアクセス
により操作する事もある。この場合は、ｇｅｔ　　ａｔ
ｔｒにより返されるファイル・サイズは、最右端のバイ
トを含むサーバーの仮想メモリのページの終端にあり、
最も最近のサーバーの周期的な同期化の前にサーバーに
書込まれたクライエント・データのみがサイズに表われ
ている。

書込みトークンを保持しているクライエントが、システ
ム・コールによりファイルのサイズを変更する事を許さ
れた唯一のノードであるとしても、ファイルに対するマ
ツプされたアクセスは、他のクライエント又はサーバー
に、直接のメモリ参照によりファイルのサイズを変化さ
せる事を可能にする。ファイルを使用している全てのク
ライエントがファイル・サイズに関して合理的に最新の
状態を保持するために、ファイルを使用している全ての
クライエントは、５ｙｎｃ　　ａｔｔｒメツセージ４９
０を用いてファイルに関する属性情報をサーバーに周期
的に送信する。サーバーの現在計算されたファイルのサ
イズは、５ｙｎｃ　　ａｔｔｒメツセージ４９０に対す
る応答中で返される。

従って、１つのクライエントにおけるファイル・サイズ
の変更は、このクライエントが５ｙｎｃ−ａｔｔｒメツ
セージを実行する時に、サーバーに伝達され、そしてフ
ァイルを使用している他のクライエントの各々がその後
そのファイルに関して５ｙｎｃ　　ａｔｔｒメツセージ
４９０を実行する時に、各クライエントに伝達される。

ファイルの属性を照会するシステム・コール、例えば５
ｔａｔシステム・コールによって返されるような、ファ
イルの変更時刻の管理は、はぼファイル・サイズの管理
と同様である。もしクライエントが、ファイルの書込み
トークンを取得する事なく、専らｐｕｔ　　ｂｙｔｅｓ
を通じて動作するならば、そのファイル変更は、最終的
には、しかし即座ではなく、サーバー又は他のクライエ
ントにおいて実行されるシステム・コールによって返さ
れる変更時刻に反映される。

しかしながら、ファイルの書込みトークンを取得し且つ
適切に管理しているクライエントは、サーバー又は他の
クライエントにおけるシステム・コールによって返され
る変更時刻が、このクライエントによるファイルに対す
る変更を適切に反映している事を、保証される。

第７Ａ図を参照すると、いくつかの事象を原因として、
サーバーが、ファイルの変更がファイル変更時刻に反映
される必要があるか否か見るために検査する。これらの
同期化事象は、下記のものである。

１）サーバーがファイルの周期的同期化を実行する（ス
テップ７ｏ１）。

２）サーバーがファイルの最後のクローズを実行する（
ステップ７０２）。

３）サーバーが、クライエントとサーバーとのファイル
に関する知識を同期化させる、ｆｓｙｎｃ等の、いくつ
かのメツセージのどれかを受取る（ステップ７０３）。

４）サーバー・プロセスが、クライエントとサーバーと
のファイルに関する知識を同期化させる、ｆｓｙｎｃ等
の、いくつかの動作のどれかを実行する（ステップ７０
４）。

同期化事象の１つが起きた時、サーバーは、それがｐｕ
ｔ　　ｂｙｔｅｓを受取っているか、又は以前の同期化
事象以来何らかのローカル・プロセスによってファイル
に記憶が行われているかを見るために検査を行う（ステ
ップ７０５．７０ｇ）。

もしそうであれば、ファイルの変更時刻は、サーバーの
現在の時刻に更新される（ステップ７０６）。

もしクライエントが、ファイルの書込みトークンを保持
する事なくｐｕｔ　　ｂｙｔｅｓによりファイルを変更
する事を選択すると、下記のシナリオが生じる。

１）クライエントＡが、ファイルをオープンし、ｇｅｔ
　　ｂｙｔｅｓにより何らかのデータを取り出す。

２）クライエントＡのプロセスが、取り出されたデータ
に記憶を行う。

３）クライエントＢのプロセスがそのファイルに関して
ｇｅｔ　　ａｔｔｒを発行する。

４）クライエントＡは書込みトークンを要求していない
ので、サーバーからクライエントＡには何のメツセージ
も送られない。

５）サーバーは、クライエントＡがファイルを変更した
事に気付かず、従ってｇｅｔ　　ａｔｔｒ中にオープン
前の変更時刻を返す。

上記の可能性を避けるために、クライエントは、ファイ
ルの書込みトークンを使用して、それらの変更の全てが
第７Ｂ図に示すようにｇｅｔ　　ａｔｔｒによって返さ
れる変更時刻中に反映されるようにする事ができる。書
込みトークンは、下記のルールに従って変更時刻を管理
するために使われる。

１）サーバーが、ファイルに関する変更カウントを記憶
している（ステップ７１０）。

２）クライエントがｇｅｔ　　ｔｋｎにより書込みトー
クンを要求する時（ステップ７１１）、変更カウントが
応答中に返される（ステップ７１２）。

３）クライエントが、後続のｇｅｔ　　ａｔｔｒの変更
時刻中にファイルの変更が反映される事を確証したい時
、クライエントは変更を行う時に変更カウントを増計数
する（ステップ７１３）。例えば、書込み（２）システ
ム・コールは、変更カウントを増計数する。

４）変更カウントは、５ｙｎｃ　　ａｔｔｒ、　　ｃｌ
ｏｓｅ、及びｒｅｖｏｋｅ　　ｔｋｎに対する応答に応
じて、サーバーに返される（ステップ７１６）。以前に
説明したように、サーバーがｇｅｔａｔｔｒを処理する
時、それは、書込みトークンを保持するクライエントに
非パージングｒｅｖｏｋｅ　　ｔｋｎを送る（ステップ
７１５）。

５）ファイルの書込みトークンを保持しているノードか
らサーバーが変更カウントを受取る時、それがどのよう
に到着したかに無関係に、サーバーはそれを、記憶して
いるカウントと比較する（ステップ７１８）。もし受取
ったカウントが記憶しているカウントよりも大きい場合
（ステップ７１９）、受取ったカウントが記憶カウント
になり、変更時刻はサーバーの現在の時刻にセットされ
る（ステップ７２０）。そうでない場合、受取ったカウ
ントは破棄される（ステップ７２１）。

従って、以前のシナリオは次のようになる。

１）クライエントＡが、ファイルをオープンし、書込み
トークンを得るためにｇｅｔ　　ｔｋｎを発行する（ス
テップ７１１）。そしてｇｅｔ　　ｂｙｔｅｓにより何
らかのデータを取り出す。

２）クライエントＡのプロセスが書込み（２）システム
・コールを発行する。これは、書込みトークンの変更カ
ウントを増計数させる（ステップ７１３）。

３）クライエントＢのプロセスがファイルに対してｇｅ
ｔ　　ａｔｔｒを発行する（ステップ７１４）。

４）サーバーが、クライエントＡに非パージングｒｅｖ
ｏｋｅ　　ｔｋｎを発行する（ステップ７１５）。返さ
れた変更カウントは、サーバーが記憶しているカウント
よりも大きいので、記憶されたカウントは更新され、サ
ーバーの現在の時刻がｇｅｔ　　ａｔｔｒ中の変更時刻
として返される（ステップ７２２．７２３）。

このシナリオでは、クライエントＡが書込みトークンを
使用する事により、その変更がｇｅｔ−ａｔｔｒにより
報告される。

少しの例外があるが、ファイルのアクセス時刻の取扱い
は、変更時刻の取扱いと類似である。それらの例外は、
以下説明する。

１つだけの書込みトークンしか存在しなければ、サーバ
ーは１つだけの変更カウントを記憶するだけでよいかも
しれない。しかしながら、複数のクライエント・ノード
が存在し、各々が読取りトークンを保持していることが
ある。従って、サーバーは、各読取りトークン毎にアク
セス・カウントを記憶しなければならない。

サーバーがｇｅｔ　　ａｔｔｒを受取る時、それは、書
込みトークンの保持者に非パージング型のｒｅｖｏｋｅ
　　ｔｋｎを発行する。これは、ファイルのクライエン
ト変更の学習を可能にする。アクセス時刻に関する類似
の動作は、サーバーが非パージングｒｅｖｏｋｅ　　ｔ
ｋｎを読取りトークンの保持者に発行する事を要求する
。しめルながら、２つの場合の間には相違点が存在する
。第一に、多くのクライエント・ノードが読取りトーク
ンを保持している可能性がある。ｒｅｖｏｋｅ−ｔｋｎ
メツセージをこれらのクライエントの各々に送る事は高
く付くであろう。第二に、ファイルが変更されたか否か
は、ファイルがアクセスされたか否かよりも重要な情報
である。

これらの理由により、及びｇｅｔ　　ａｔｔｒは比較的
頻繁な要求であるという事実を考慮して、プロトコルは
、読取りトークンの保持者がｇｅｔａｔｔｒに対するサ
ーバーの応答の一部としてポーリングされる事を要求し
ない。クライエント及びサーバーの周期的な同期化動作
は、システム・コールを介するアクセスを、（クライエ
ント及びサーバーの周期的な同期化の頻度に依存して）
最終的にアクセス時刻属性中に現れさせる。ファイルの
読取りトークンの利点を伴わない、ｇｅｔ−ｂｙｔｅｓ
によるアクセスは、アクセス時刻属性中に反映されない
。

上述のように、ファイル属性は、読取り及び書込みトー
クン中に保持されている。ファイル・・サイズ及び変更
時刻属性は書込みトークン中に保持され、アクセス時刻
属性は読取りトークン中に保持される。読取り及び書込
みトークン中にファイル属性を保持する事は、読取り及
び書込み動作を実行しているプロセスにとって有用であ
る。プロセスは、書込みトークンを取得する必要がなく
、マツプされたアクセスを通してファイルを拡張し、そ
れによってファイル・サイズ属性を変化させ且つ時刻属
性を変更するので、ファイル・サイズ属性は、トークン
中に記憶されるだけでなく、ファイルの最右端のページ
にも記憶される。ファイルの最右端のページは、ファイ
ルのサイズとは異なっている事がある。ファイルの最右
端のページは、仮想メモリ・マネジャによって知られて
いる。仮想メモリ・マネジャは、ファイルの正確なサイ
ズは知らないが、ファイルの最右端のページは知ってい
る。従って、プロセスは、ファイルの最右端のページを
延長する仮想メモリ・マネジャによってファイルを拡張
する事ができ、又プロセスは書込みトークンを通じてフ
ァイルに書込み且つファイルを拡張する事ができる。

サーバーは、クライエントにおける書込みトークン内に
含まれる情報と最右端のページからの情報とを組合せて
、これらのファイル属性を要求する他のクライエントか
らの要求に応答して、ファイルの現在のサイズに到達す
る。

マツプされたアクセスを通じてファイルを拡張するプロ
セスは、そのプロセスによりファイルがクローズされる
時に最右端のページを通じて、又は周期的な同期化動作
により、ファイルのサイズをサーバーに返す。

全てのクライエントは、ｐｕｔ　　ｂｙｔｅｓメツセー
ジを用いて変更されたデータをサーバーに周期的に送ら
なければならない。これは、サーバーに、クライエント
がファイルを拡張した時を知る事を可能にする。次に、
サーバーは、この情報を用いてファイルに関するｉノー
ド・データ構造を更新する。

もしクライエントがサーバーに最新の属性を要求すると
、サーバーは、トークン中に記憶された属性値に関する
現在の情報を求めてトークンを有するクライエントに要
求を送る。クライエントからの属性取得要求に応答して
、サーバーは、書込みトークンを保持しているクライエ
ントにトークン取消しメツセージを送る。このトークン
取消しメ・ンセージは、クライエントに書込みトークン
を失なわせない特別なトークン取消しメツセージである
。その代りに、クライエントは、書込みトークンを保持
しながら、ファイル属性を有する書込みトークンのコピ
ーをサーバーに送る。次に、サーバーは、書込みトーク
ンからのこの情報及び最右端のページを使用して、別の
クライエントからの属性取得要求に答える。

下記の事象のどれかが起きると、サーバーのファイル・
サイズ属性が調整される。もしサーバーがファイルの周
期的同期化、ファイルの最終のクローズ、又はｆ　　５
ｙｎｃ要求を実行するならば、サーバーはファイル属性
のサイズを最右端のページに調整する。

Ｆ０発明の効果 本発明によれば、サイズ、最後の変更の時刻、及び最後
のアクセスの時刻等のファイル属性が分散処理環境中の
全てのクライエントにおいて正確であり且つ利用可能で
あるように維持される。又、その維持管理は、不当なオ
ーバーヘッド、性能コスト及びネットワーク・トラフィ
ックなしに行われる。

【図面の簡単な説明】

第１図は本発明の分散データ処理システム中のクライエ
ントデータ処理システムとサーバーデータ処理システム
を示す図、 第２Ａ図はシステム・コールを通うてファイルにアクセ
スする事に関して従来技術のスタンドアローンのデータ
処理システムを示すブロック図、第２Ｂ図はマツプ式の
ファイル・アクセスを示す従来技術のスタンドアローン
のデータ処理システムを示すブロック図、 第３図はシステム・コールを通じてファイルにアクセス
する第２図のデータ処理システムの流れ図、 第４Ａ〜４工図は種々のメツセージのデータ構造を示す
図、 第５図は従来技術で知られている分散データ処理システ
ムのブロック図、 第６Ａ図は２つのクライエントが同じデータに書込み許
可を要求する時のノード間メツセージの系列を示す流れ
図、 第６Ｂ図は他のクライエントが変更を行っているファイ
ルの属性をあるクライエントが要求する時の流れ図、 第６Ｃ図は１つのクライエントがファイルに対して読取
り又は読み書きの許可を要求し、且つ他のクライエント
がファイルの属性を要求する時に、サーバーが最新のフ
ァイル属性を維持する手続きを示す流れ図、 第６Ｄ図はサーバーに記憶されているファイル・サイズ
を仮想メモリ・マネジャの最右端のページと矛盾のない
ようにする、サーバーでの動作を示す流れ図、 第７Ａ図はサーバーにファイルの変更時間を更新させる
事象を示す流れ図、 第７Ｂ図はクライエントがファイルに書込みを行う時に
サーバーが最新のファイル変更時間を維持する手続きを
示す流れ図である。

Claims (25)

【特許請求の範囲】
1. （１）通信手段により少なくとも１つのクライエント・
   データ処理システムに接続されたサーバー・データ処理
   システムに存在するファイルの第１のファイル・サイズ
   を維持する方法であって、上記少なくとも１つのクライ
   エント・データ処理システムにおいてファイル・サイズ
   を変更する能力と共に第２のファイル・サイズを維持す
   るステップと、 上記少なくとも１つのクライエント・データ処理システ
   ムによって上記第２のファイル・サイズを変更するステ
   ップと、 サーバー・データ処理システムによって、上記クライエ
   ント・データ処理システムからの上記第２のファイル・
   サイズを、サーバー・データ処理システムにおける上記
   第１のファイル・サイズと組合せて最新のファイル・サ
   イズ値を決定するステップとを含む方法。
2. （２）サーバー・データ処理システムによって、上記最
   新のファイル・サイズを決定する前に、上記少なくとも
   １つのクライエント・データ処理システムの少なくとも
   １つから上記第２のファイル・サイズに関する情報を取
   得するステップを含む請求項１に記載の方法。
3. （３）サーバー・データ処理システムから少なくとも１
   つのクライエント・データ処理システムの少なくとも１
   つに送られた要求に応答して上記第２のファイル・サイ
   ズを受け取るステップを含む請求項２に記載の方法。
4. （４）クライエント・データ処理システムがクライエン
   ト・データ処理システムで変更されたデータを周期的に
   サーバー・データ処理システムに書込む時に、上記少な
   くとも１つのクライエント・データ処理システムの少な
   くとも１つから上記第２のファイル・サイズを受け取る
   ステップを含む請求項２に記載の方法。
5. （５）クライエント・データ処理システムが周期的な同
   期化動作を行う時に、上記少なくとも１つのクライエン
   ト・データ処理システムの少なくとも１つから上記第２
   のファイル・サイズを受け取るステップを含む請求項２
   に記載の方法。
6. （６）最新のファイル・サイズ値を決定する前に上記第
   ２のファイル・サイズに関する上記要求を上記少なくと
   も１つのクライエント・データ処理システムの少なくと
   も１つが受け取るべき事をサーバー・データ処理システ
   ムに通知するステップを含む請求項２に記載の方法。
7. （７）上記クライエント・データ処理システムが上記要
   求を受け取るべき事を示すためにトークンを使用し、上
   記トークンは、上記クライエント・データ処理システム
   がファイルに書込む許可を要求する時に上記クライエン
   ト・データ処理システムによって上記サーバー・データ
   処理システムから要求される、請求項６に記載の方法。
8. （８）上記少なくとも１つのクライエント・データ処理
   システムに上記決定された最新のファイル・サイズ値を
   送るステップを含む請求項２に記載の方法。
9. （９）上記少なくとも１つのクライエント・データ処理
   システムに上記決定された最新のファイル・サイズ値を
   送るステップを含む請求項５に記載の方法。
10. （１０）上記少なくとも１つのクライエント・データ処
    理システムにおいて、仮想メモリのアクセスを通じて及
    びシステム・コールのアクセスを通じて、上記ファイル
    ・サイズを変更する能力と共に上記第２のファイル・サ
    イズを維持する請求項１に記載の方法。
11. （１１）最右端の仮想メモリ・ページ内に含まれるファ
    イル終端を通じて最新のファイル・サイズ値を決定する
    請求項１１に記載の方法。
12. （１２）サーバー・データ処理システムにおいて、少な
    くとも１つのクライエント・データ処理システムから受
    け取ったファイル・サイズに関する要求に応答して最新
    のファイル・サイズを決定し、上記最新のファイル・サ
    イズ値を上記少なくとも１つのクライエント・データ処
    理システムに返す請求項１に記載の方法。
13. （１３）サーバー・データ処理システムにより、上記少
    なくとも１つの属性の上記最新の値の決定を行う前に上
    記少なくとも１つのクライエント・データ処理システム
    に上記ファイル・サイズに関する少なくとも１つの要求
    を送る事によって、上記少なくとも１つのクライエント
    ・データ処理システムから上記ファイル・サイズに関す
    る情報を受け取る請求項１に記載の方法。
14. （１４）通信手段を介して少なくとも１つのクライエン
    ト・データ処理システムに接続されたサーバー・データ
    処理システムに存在するファイルの第１のファイル・サ
    イズを維持する方法であって、サーバー・データ処理シ
    ステムからファイルに書込む許可を受けている上記クラ
    イエント・データ処理システムの１つにより、上記書込
    み許可と共にファイルの第２のファイル・サイズ維持す
    るステップと、 上記クライエント・データ処理システムが上記ファイル
    を変更する時に、上記第２のファイル・サイズを更新す
    るステップと、 ファイルに関する書込み許可を有しているクライエント
    ・データ処理システムからの情報及びファイルの最右端
    のページを組合せて、サーバー・データ処理システムに
    より、最新のファイル・サイズを決定するステップとを
    含む方法。
15. （１５）ファイルへのマップ式アクセスを有している上
    記クライエント・データ処理システムの１つにより、サ
    ーバー・データ処理システムへ、ファイルに対する変更
    を周期的に送り、クライエント・データ処理システムが
    マップ式アクセスによりファイルを拡張した時にサーバ
    ー・データ処理システムが該拡張を知りうるようにした
    請求項１４に記載の方法。
16. （１６）上記組合せのステップが、上記クライエント・
    データ処理システムの１つによるファイル・サイズに関
    する要求に応答してサーバー・データ処理システムによ
    り実行される請求項１４に記載の方法。
17. （１７）サーバー・データ処理システムにおいて、サー
    バーが周期的なファイルの同期化動作を実行する場合に
    ファイルの最右端のページに対応するように最新のファ
    イル・サイズを調整するステップを含む請求項１４に記
    載の方法。
18. （１８）サーバー・データ処理システムにおいて、ファ
    イルの最後のクローズの後で、ファイルの最右端のペー
    ジに対応するように最新のファイル・サイズを調整する
    ステップを含む請求項１４に記載の方法。
19. （１９）サーバー・データ処理システムにおいて、上記
    クライエント・データ処理システムの１つにおける全て
    の変更をサーバー・データ処理システムに記憶する要求
    中に、ファイルの最右端のページに対応するように最新
    のファイル・サイズを調整するステップを含む請求項１
    ４に記載の方法。
20. （２０）調整ステップがｆ＿ｓｙｎｃ動作中に実行され
    る請求項１９に記載の方法。
21. （２１）通信手段により少なくとも１つのクライエント
    ・データ処理システムに接続されたサーバー・データ処
    理システムに存在するファイルの変更時刻を維持する方
    法であって、 サーバー・データ処理システムにより、ファイルに関す
    る変更カウント及び対応する変更時刻を追跡するステッ
    プと、 書込み許可を有するクライエント・データ処理システム
    により、クライエント・データ処理システムがファイル
    を変更する時に変更カウントを増計数するステップと、 クライエント・データ処理システムから、サーバー・デ
    ータ処理システムへ、周期的な同期化動作時に変更カウ
    ントを送るステップと、 サーバー・データ処理システムにより、上記送られた変
    更カウントと上記追跡された変更カウントとを比較して
    、クライエント・データ処理システムが書込み許可を有
    している間にファイルが変更されたか否かを判定するス
    テップと、 サーバー・データ処理システムにより、上記比較結果か
    らファイルが変更されたと判定された場合、対応する上
    記追跡された変更時刻を上記送られた変更時刻に更新す
    るステップとを含む方法。
22. （２２）通信手段により少なくとも１つのクライエント
    ・データ処理システムに接続されたサーバー・データ処
    理システムにおけるファイルの変更時刻を維持する方法
    であって、クライエント・データ処理システムによりフ
    ァイルに書込むためのサーバー・データ処理システムか
    らの許可と共に変更カウント及び対応する変更時刻を維
    持するステップと、 サーバー・データ処理システムによりファイルに関する
    変更カウントを追跡するステップと、書込み許可を有す
    るクライエント・データ処理システムにより、クライエ
    ント・データ処理システムがファイルを変更した時に変
    更カウントを増計数するステップと、 クライエント・データ処理システムからサーバー・デー
    タ処理システムへ、サーバー・データ処理システムから
    の要求に応じて変更カウントを送るステップと、 サーバー・データ処理システムにより、上記送られた変
    更カウントと上記追跡された変更カウントとを比較して
    、クライエント・データ処理システムが書込み許可を有
    している間にファイルが変更されたか否かを判定するス
    テップと、 サーバー・データ処理システムにより、上記比較結果か
    らファイルが変更されたと判定された場合、上記追跡さ
    れた変更時刻を上記送られた変更時刻に更新するステッ
    プとを含む方法。
23. （２３）通信手段により少なくとも１つのクライエント
    ・データ処理システムに接続されたサーバー・データ処
    理システムにおけるファイルのアクセス時刻を維持する
    方法であって、 少なくとも１つのクライエント・データ処理システムの
    １つによりファイルを読取るためのサーバー・データ処
    理システムからの許可と共にクライエント・アクセス時
    刻を維持するステップと、読取り許可を有するクライエ
    ント・データ処理システムにより、クライエント・デー
    タ処理システムがファイルにアクセスした時にクライエ
    ント・アクセス時刻を増計数するステップと、 読取り許可を有する上記クライエント・データ処理シス
    テムの各々から、サーバー・データ処理システムへ、対
    応するクライエント・アクセス時刻を送るステップと、 サーバー・データ処理システムにより、上記送られたク
    ライエント・アクセス時刻とサーバー・データ処理シス
    テムにおける記録されたアクセス時刻とを比較して、ク
    ライエント・データ処理システムが読取り許可を有して
    いる間にファイルがアクセスされたか否かを判定するス
    テップと、サーバー・データ処理システムにより、上記
    比較結果からファイルがアクセスされたと判定された場
    合、上記記録されたアクセス時刻を上記送られたクライ
    エント・アクセス時刻に更新するステップとを含む方法
    。
24. （２４）周期的に送信するステップが、読取り許可を有
    するクライエント・データ処理システムの各々により、
    ｓｙｎｃ＿ａｔｔｒメッセージを通じて実行される請求
    項２３に記載の方法。
25. （２５）通信手段を介して少なくとも１つのクライエン
    ト・データ処理システムに接続可能なサーバー・データ
    処理システムに存在するファイルの第１のファイル・サ
    イズを維持する手段を有するサーバー・データ処理シス
    テムで使用されるコンピュータ・プログラム製品であっ
    て、 サーバー・データ処理システムからファイルに書込む許
    可を受けている上記クライエント・データ処理システム
    の１つから、上記書込み許可と共に上記クライエント・
    データ処理システムにより維持され且つ上記クライエン
    ト・データ処理システムがファイルを変更する時に更新
    可能な第２のファイル・サイズを要求する手段と、 マップ式アクセスによりファイルを拡張している上記少
    なくとも１つの上記クライエント・データ処理システム
    からファイルの最右端のページを周期的に受け取る手段
    と、 サーバー・データ処理システムにより、ファイルに関し
    て書込み許可を有しているクライエント・データ処理シ
    ステムから第２の更新可能なファイル・サイズと、ファ
    イルの最右端のページとを組合せて、上記サーバー・デ
    ータ処理システムで維持されている最新のファイル・サ
    イズを決定する手段とを含むコンピュータ・プログラム
    製品。