JP2003530646A

JP2003530646A - トランザクショナルファイルシステム

Info

Publication number: JP2003530646A
Application number: JP2001575287A
Authority: JP
Inventors: ベルマサレンドラ; ジェイ．ミラートーマス; ジー．アトキンソンロバート
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2000-03-30
Filing date: 2001-03-16
Publication date: 2003-10-14
Anticipated expiration: 2021-03-16
Also published as: CN100445998C; CN1746893B; CN1449530A; US20130325830A1; CN1746892A; WO2001077908A2; US20100042626A1; JP4219589B2; CN1746893A; US20050120059A1; US8510336B2; WO2001077908A3; US7613698B2; US7418463B2; US6856993B1; US20050120036A1; CN100337233C; EP1269353A2; US20110276611A1; US20050149525A1

Abstract

(57)【要約】複数のファイルシステム動作をユーザレベルトランザクションの一部として実行することができるトランザクショナルファイルシステム。アプリケーションは、ファイルに対する動作またはスレッドのファイルシステム動作が、トランザクションの一部として処理されなければならないことを指定し、アプリケーションにトランザクションコンテキストに関連するファイルハンドルが与えられる。トランザクションコンテキストに関連するファイルシステム要求に関して、ファイルシステム内のコンポーネントが、トランザクショナル挙動との一貫性を有する動作を管理する。コンポーネントは、分散トランザクションのリソースマネージャとすることができるが、変更されたページのコピーを追跡することによってファイルの複数のバージョンを提供することによってデータ分離を提供し、トランザクショナルリーダーが、トランザクショナルライタがトランザクションをコミットし、リーダーがファイルを再オープンするまで、トランザクショナルライタによって行われるファイルに対する変更を受け取らなくなる。コンポーネントは、ログ記録および回復を容易にする複数レベルログでの名前空間ログ記録動作も処理する。ページデータもまた、メインログと別にログ記録され、システムクラッシュの前にページが完全にディスクにフラッシュされたかどうかをログが判定できるようにする一意の署名を有する。名前空間分離は、トランザクションが分離ディレクトリを介してコミットするまで提供され、これによって、コミットされるまでは、トランザクションが、それ自体の動作の影響を見るが、他のトランザクションの動作の影響は見ない。ネットワーク上のトランザクションも、リダイレクタプロトコルを介して容易にされる。

Description

【発明の詳細な説明】

【０００１】（発明の分野）本発明は、一般的にコンピュータシステムおよびファイルシステムを対象とす
る。

【０００２】（発明の背景）通常のファイルシステムは、ファイルまたはディレクトリの新規作成、ファイ
ルまたはディレクトリの削除または名前の変更、およびファイル内容の操作を含
む、ファイル階層を操作する機構を提供する。特定のファイルシステムは、単一
の下位動作すなわちプリミティブの完了に関するある保証を提供する。たとえば
、ファイルを新規作成するプリミティブは、成功裡に完了するか、またはそのフ
ァイル作成動作の何らかの部分的な効果がシステムによって元に戻される（アン
ドゥされる）かのいずれかになる。

【０００３】しかし、ユーザレベルでの複数のファイルシステム動作は、ファイルシステム
内で一緒に結びつけられない可能性がある。たとえば、現在、ファイルシステム
が、４つのファイルを作成し、３つの他のファイルを削除し、もう１つのファイ
ルの名前を変更するが、これらの動作のどれかが失敗した場合に、他の動作のい
ずれかを元に戻す方法はない。その結果、アプリケーションなどの上位（ユーザ
レベル）処理が、そのような複数の動作の管理すなわち、どのアクションをどの
ファイルおよび／またはディレクトリに適用するかをファイルシステムに指定す
るのに使用される。

【０００４】しかし、この解決策にはそれ自体の短所がある。ウェブサイトが、一貫したル
ックアンドフィールをサイトに与える形で互いにリンクされた２０個のウェブペ
ージを有する例を検討する。サイトの更新中に、システムに障害が発生し、一貫
性のない状態が引き起こされる可能性がある。たとえば、更新を実行するアプリ
ケーションが、障害の時点で、一部のファイルを削除し終えたが、これらのファ
イルをポイントしていた他のファイルからのリンクを削除していない場合がある
。このサイトを見るユーザは、ウェブページの一部を見るが、削除されたページ
へのリンクをクリックした時にエラーメッセージを受け取る。

【０００５】一貫性のない状態で終わる可能性に対して保護するためには、ウェブページフ
ァイル階層全体を、階層内のファイルを変更する前に普通にコピーする。障害の
場合に、保存された階層をコピーバックする。しかし、このファイルのコピーは
低速であり、コピープログラムが、システムのどの部分が更新されるかを事前に
知る必要があり、ファイルのどれかが偶然にコピーされない場合に回復不能にな
るので、エラーになりやすいという点で比較的ぎこちない。

【０００６】ファイルが定位置で変更される場合、上位処理を使用してファイルを更新する
時に、進行中のどんな変更も、サイトを見るユーザに可視になる。たとえば、上
で説明したウェブサイトでは、どんな変更も、ファイル（および名前階層）がア
プリケーションによって変更されている間に、システムの既存のユーザに可視に
なる。システム状態は、通常、すべての変更が行われるまでは一貫性がないので
、ユーザは、その一貫性のなさを見る可能性がある。たとえば、既存のユーザが
、ウェブページ内のリンク（ＵＲＬ）を見、それをクリックし、削除されたペー
ジで終わる場合があり、これは、アプリケーションがページを削除したが、その
ページをポイントするリンクをまだ除去していない時に発生するイベントである
。

【０００７】ウェブページ更新のほかに、他のプログラムが、一貫性のある形で情報を保存
する能力を同様に制限される。たとえば、通常のワードプロセッサアプリケーシ
ョンまたはスプレッドシートアプリケーションは、システム障害の後に発生する
可能性がある一貫性のない状態を回避するために、一時ファイルを使用して、名
前の変更動作および削除動作によって完全な保存を実行する。そのようなアプリ
ケーションが、異なるデータソースにまたがって情報を分配しようとする場合も
ある。たとえば、アプリケーションが、表データをＳＱＬＳｅｒｖｅｒに保管
し、ファイルをファイルサーバおよび／またはインターネットサーバに保管しよ
うとする場合があり、たとえば、そのようなファイルに、ワードプロセッサ文書
、プレゼンテーションチャート、および／またはウェブページが含まれる場合が
ある。しかし、調整され統一された形でのそのような情報の保存をサポートする
機構は、現在存在しない。たとえば、そのような情報の保存中にシステムが障害
を発生する場合に、情報の一部が保存されるが、それ以外は保存されず、やはり
一貫性のない状態につながる。

【０００８】（発明の概要）簡単に言えば、本発明は、それを介して複数のファイルシステム動作を単一の
ユーザレベルトランザクションの一部として実行することができる、システムお
よび方法を提供する。本発明のトランザクショナルファイルシステムは、ユーザ
が、ファイルシステム内のトランザクションのスコープおよび期間を選択的に制
御できるようにする。

【０００９】ファイルのオープン中または作成中に、アプリケーションが、そのファイルオ
ープンのインスタンスに対する動作がトランザクションの一部として扱われなけ
ればならないかどうかを指定する。さらに、このシステムは、トランザクショナ
ルに操作することだけができるファイルを永続的にマークする能力を提供し、ア
プリケーションは、オープン／作成時にグローバル一意ｉｄ（ＧＵＩＤ）を介し
てトランザクションを指定する。新規ファイル作成に関して、親ディレクトリが
、被トランザクションとしてマークされ、アプリケーションは、トランザクショ
ンをスレッド／プロセスに関連付けることができ、これによって、そのようなス
レッド／プロセスによるファイル操作が、指定されたトランザクションのコンテ
キスト内でトランザクション処理される。さらに、アプリケーションは、子スレ
ッド／プロセスがトランザクションコンテキストを継承することをシステムに指
示する（たとえばＡＰＩを介して）ことを選択することができ、アプリケーショ
ンが、アプリケーションソースコードに対する大きい変更なしで、トランザクシ
ョンを利用できるようになる。

【００１０】ファイルがトランザクション的にオープンされた後に、このシステムは、ファ
イルのハンドルに対する読取、書込、削除、または名前の変更などの動作を、ト
ランザクションの一部として自動的に含める。その結果、アプリケーションは、
既存のファイルシステムＡＰＩを呼び出し、既存の動作単位のセマンティクスを
見続け、なおかつトランザクションの一部として動作を含めることができる。ア
プリケーションは、使いたいだけいくつでもトランザクションを使用することが
でき、他のアプリケーションとトランザクションを共有することができ、望みの
数のスレッド／プロセスにトランザクションを共有させることなどができる。ト
ランザクションは、異なるコンピュータに常駐するファイルに関して行われるフ
ァイルオープンの際に指定することができる。

【００１１】本発明の他の態様は、障害が発生したトランザクションからの回復可能性を使
用可能にするためのログ記録を対象とする。トランザクションの下で、システム
によって行われる変更は、システム障害およびアプリケーション障害を含むなん
らかの理由でトランザクションに障害が発生した場合に元に戻され、そのトラン
ザクションに関してシステムによって行われる変更は、システムがアプリケーシ
ョンの代わりにトランザクションを成功裡にコミットする場合に、システム障害
（たとえば停電）に耐えることが保証される。これは、複数レベルログ記録機構
と、より下位のログ記録される動作が成功裡にコミットされたかどうかを判定し
、これによって、より上位のログ記録される動作が実際に発生したかどうかを判
定する機構とを介して達成される。

【００１２】データ変更は、動作イベントを１つのログに、また、トランザクションの実際
のデータ書込の詳細を別のログ、たとえばページストリームに分離することによ
ってもログ記録される。ある機構がログ記録された署名を書き込み、後でログ記
録されたレコードおよびデータの両方と比較して、ログ記録されたレコードがそ
れに対応するデータページと同期化されているかどうかを判定し、ログがデータ
に関して特定の順序でディスクに書き込まれるという要件をなくす。

【００１３】本発明の他の態様には、トランザクションおよび他のファイルシステム動作の
間での名前空間およびファイルデータの分離の提供が含まれる。名前空間分離は
、どの名前がどのトランザクションに属するかを追跡する分離ディレクトリの使
用によって達成される。その結果、変更するトランザクションがまだアクティブ
である間、所与のトランザクションについてシステムによって行われる変更のど
れもが他のトランザクションにとって不可視になり、変更するトランザクション
が成功裡にコミットした後に限って可視になる。トランザクション非対応ファイ
ルハンドルは、変更が起きた時にその変更を見る。したがって、第１トランザク
ション中に削除されるファイルは、もはやその第１トランザクションまたは非ト
ランザクションによって見られなくなるが、第１トランザクションが完了するま
では、他のトランザクションから可視のままになる。

【００１４】そのような名前空間分離を達成するために、元のＮＴＦＳディレクトリにリン
クされた分離ディレクトリが作成され、通常のＮＴＦＳ親ディレクトリではなく
、分離ディレクトリに適当なファイル名が追加される。たとえば、削除動作に関
して、削除されるファイルの名前が、そのファイルがＮＴＦＳ親ディレクトリか
ら除去されるのと同時に、分離ディレクトリに追加される。コミットの前には、
異なるトランザクションによるこのファイルへの後続アクセスが、分離ディレク
トリを使用してサービスされ、これによって、そのファイルが見つかり、削除さ
れていないとみなされる。同様に、トランザクションがファイルを作成する場合
に、その名前が、ＮＴＦＳディレクトリならびに親ＮＴＦＳディレクトリにリン
クされた分離ディレクトリに追加される。そのファイルを作成したトランザクシ
ョンは、そのファイルを見るが、他のトランザクションにとって、その名前は、
ファイルのオープンまたは親ＮＴＦＳディレクトリのリスティングに関してフィ
ルタアウトされる。分離ディレクトリエントリは、トランザクションがコミット
するか中断する時に、分離ディレクトリから除去される。

【００１５】したがって、本発明は、トランザクション機構をファイルシステムに組み込み
、アプリケーションが１つまたは複数のファイルに対して複数のトランザクショ
ナル動作を簡単に実行できるようにし、外部トランザクション機構に関連する問
題を克服する。このようにして、複数のファイルシステム動作を、ファイルシス
テム内でトランザクション的な形で一緒に結び付け、動作が一緒にコミットされ
るか、部分的なアクションのいずれもが元に戻されるかのどちらかになるように
する。さらに、１つのトランザクションの動作およびデータ変更が、別のトラン
ザクションの動作およびデータから分離される。

【００１６】他の長所は、図面と共に下の詳細な説明を考慮することから明白になる。

【００１７】（発明の詳細な説明）例示的オペレーティング環境図１および以下の説明は、本発明を実施することができる適当なコンピューテ
ィング環境の短い一般的な説明を提供することを意図されたものである。必要で
はないが、本発明を、プログラムモジュールなどのパーソナルコンピュータによ
って実行されるコンピュータ実行可能命令の一般的な文脈で説明する。一般に、
プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネ
ント、データ構造体、および、特定のタスクを実行するかまたは特定の抽象デー
タ型を実施する類似物が含まれる。

【００１８】さらに、当業者は、ハンドヘルドデバイス、マルチプロセッサシステム、マイ
クロプロセッサベースまたはプログラマブルな消費者電子製品、ネットワークＰ
Ｃ、ミニコンピュータ、メインフレームコンピュータ、および類似物を含む、他
のコンピュータシステム構成を用いて本発明を実践できることを諒解するであろ
う。本発明は、通信ネットワークを介してリンクされたリモート処理装置によっ
てタスクが実行される分散コンピューティング環境でも実践することができる。
分散コンピューティング環境では、プログラムモジュールを、ローカルとリモー
トの両方のメモリストレージデバイスに配置することができる。

【００１９】図１を参照すると、本発明を実施する例示的システムに、普通のパーソナルコ
ンピュータ２０または類似物の形の汎用コンピューティングデバイスが含まれ、
このパーソナルコンピュータ２０には、処理ユニット２１、システムメモリ２２
、および、システムメモリを含むさまざまなシステム構成要素を処理ユニット２
１に結合するシステムバス２３が含まれる。システムバス２３は、メモリバスま
たはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのい
ずれかを使用するローカルバスを含む、複数のタイプのバス構造のいずれかとす
ることができる。システムメモリには、読取専用メモリ（ＲＯＭ）２４およびラ
ンダムアクセスメモリ（ＲＡＭ）２５が含まれる。起動中などにパーソナルコン
ピュータ２０内の要素の間の情報の転送を助ける基本ルーチンを含む基本入出力
システム２６（ＢＩＯＳ）が、ＲＯＭ２４に保管される。パーソナルコンピュー
タ２０には、さらに、図示されないハードディスクから読み取り、これに書き込
むハードディスクドライブ２７、取外し可能磁気ディスク２９から読み取り、こ
れに書き込む磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたは他の光学媒
体などの取外し可能光ディスク３１から読み取り、これに書き込む光ディスクド
ライブ３０が含まれる。ハードディスクドライブ２７、磁気ディスクドライブ２
８、および光ディスクドライブ３０は、それぞれハードディスクドライブインタ
ーフェース３２、磁気ディスクドライブインターフェース３３、および光学ドラ
イブインターフェース３４によってシステムバス２３に接続される。ドライブお
よびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構
造体、プログラムモジュール、およびパーソナルコンピュータ２０の他のデータ
の不揮発性ストレージを提供する。本明細書で説明する例示的実施形態ではハー
ドディスク、取外し可能磁気ディスク２９、および取外し可能光ディスク３１が
使用されるが、磁気カセット、フラッシュメモリカード、ディジタルビデオディ
スク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取専用
メモリ（ＲＯＭ）、および類似物などの、コンピュータによってアクセス可能な
データを保管することができる他のタイプのコンピュータ可読媒体を、例示的動
作環境で使用できることを、当業者は諒解するであろう。

【００２０】オペレーティングシステム３５（好ましくは、ＭｉｃｒｏｓｏｆｔＣｏｒｐ
ｏｒａｔｉｏｎ社のＷｉｎｄｏｗｓ（登録商標）２０００、旧称Ｗｉｎｄｏｗｓ
（登録商標）ＮＴ）を含む複数のプログラムモジュールを、ハードディスク、磁
気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に保管するこ
とができる。コンピュータ２０には、ＷｉｎｄｏｗｓＮＴ（登録商標）ファイ
ルシステム（ＮＴＦＳ）などの、オペレーティングシステム３５に関連するか含
まれるファイルシステム３６、１つまたは複数のアプリケーションプログラム３
７、他のプログラムモジュール３８、およびプログラムデータ３９が含まれる。
ユーザは、キーボード４０およびポインティングデバイス４２などの入力デバイ
スを介してパーソナルコンピュータ２０にコマンドおよび情報を入力することが
できる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、
ゲームパッド、衛星放送用パラボラアンテナ、スキャナ、または類似物を含める
ことができる。これらおよび他の入力デバイスは、しばしば、システムバスに結
合されるシリアルポートインターフェース４６を介して処理ユニット２１に接続
されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌｓｅｒ
ｉａｌｂｕｓ（ＵＳＢ）などの他のインターフェースによって接続することが
できる。モニタ４７または他のタイプのディスプレイデバイスも、ビデオアダプ
タ４８などのインターフェースを介してシステムバス２３に接続される。モニタ
４７のほかに、パーソナルコンピュータには、通常は、スピーカおよびプリンタ
などの他の周辺出力デバイス（図示せず）が含まれる。

【００２１】パーソナルコンピュータ２０は、リモートコンピュータ４９などの１つまたは
複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環
境で動作することができる。リモートコンピュータ４９は、もう１つのパーソナ
ルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他
の一般的なネットワークノードとすることができ、メモリストレージデバイス５
０だけが図１に示されているが、通常は、パーソナルコンピュータ２０に関して
上で説明した要素の多数またはすべてが含まれる。図１に示された論理接続には
、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ
）５２が含まれる。そのようなネットワーキング環境は、オフィス、企業全体の
コンピュータネットワーク、イントラネット、およびインターネットでありふれ
たものである。

【００２２】ＬＡＮネットワーキング環境で使用される時には、パーソナルコンピュータ２
０は、ネットワークインターフェースまたはネットワークアダプタ５３を介して
ローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用さ
れる時には、パーソナルコンピュータ２０に、通常はモデム５４または、インタ
ーネットなどの広域ネットワーク５２を介する通信を確立する他の手段が含まれ
る。モデム５４は、内蔵または外付けとすることができるが、シリアルポートイ
ンターフェース４６を介してシステムバス２３に接続される。ネットワーク化さ
れた環境では、パーソナルコンピュータ２０に関して図示されたプログラムモジ
ュール、またはその一部を、リモートメモリストレージデバイスに保管すること
ができる。図示のネットワーク接続が、例示的であり、コンピュータの間で通信
リンクを確立する他の手段を使用することができることを諒解されたい。

【００２３】本発明を、Ｗｉｎｄｏｗｓ（登録商標）２０００オペレーティングシステムお
よびＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓＮＴ（登録商標）ファイルシステム
（ＮＴＦＳ）に関して説明するが、当業者は、他のオペレーティングシステムお
よび／またはファイルシステムを実施でき、本発明から利益を得ることができる
ことを諒解するであろう。

【００２４】トランザクショナルファイルシステムの一般的アーキテクチャ一般に、本明細書で使用される用語「トランザクション」、「トランザクショ
ナル」などは、本発明で複数のファイルシステム動作に適用される、ある共通の
プロパティを有する動作を指す。トランザクショナルプロパティを、通常は「Ａ
ＣＩＤ」プロパティと称し、これは、ａｔｏｍｉｃｉｔｙ（原子性）、ｃｏｎｓ
ｉｓｔｅｎｃｙ（一貫性）、ｉｓｏｌａｔｉｏｎ（分離）、およびｄｕｒａｂｉ
ｌｉｔｙ（耐久性）を表す。以下で理解されるように、本発明は、ファイルシス
テムと共同してこれらのプロパティを達成し、アプリケーションおよびコンピュ
ーティング一般に多数の利益をもたらす。

【００２５】図２に一般的に示されているように、アプリケーション６０または類似物から
ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓＮＴ（登録商標）ファイルシステム（Ｎ
ＴＦＳ）３６（図１）などのトランザクション対応ファイルシステム６２（本発
明に関して本明細書で説明される）に向けられたファイルシステム要求５８が、
ディスパッチ機構６６を介してＮＴＦＳコンポーネント６４に達する。従来のフ
ァイルシステムに関して既知のように、たとえばＩ／Ｏ要求パケット（ＩＲＰ）
がＩ／Ｏマネージャによってファイルシステムに送られることをもたらす可能性
があるこれらの要求を生成するために、アプリケーション６０が、アプリケーシ
ョンプログラミングインターフェース（ＡＰＩ）呼出しを行うことができる。本
発明によれば、以下で説明するように、ファイルシステム要求５８のいくつかが
、トランザクションに関連し、それ以外はそうでない可能性がある。

【００２６】トランザクションがない場合に、ファイルシステム要求５８は、本質的に本発
明の前と同一の形で、ＮＴＦＳコンポーネント６４によって直接にディスパッチ
され、処理される。同様に、以下で説明するように、トランザクションによって
開始されるか、オープントランザクションによって変更されたファイルまたはデ
ィレクトリに向けられた要求５８は、普通にＮＴＦＳコンポーネント６４に、お
よびＮＴＦＳコンポーネント６４からディスパッチされ続ける。しかし、そのよ
うなトランザクショナル要求は、それ以外は通常の処理中の戦略的なポイントで
、ファイルシステム６２の内部で実装されるものなどのＴｘＦコンポーネント７
０へのコールアウト（コールバック）をもたらす。

【００２７】図２に示され、以下で説明されるように、ＴｘＦコンポーネント７０には、外
部トランザクションサービス７２およびログ記録サービス７４へのインターフェ
ースが含まれ、ＴｘＦコンポーネント７０は、ＮＴＦＳコンポーネント６４と共
に働いて、トランザクショナル要求を処理する。外部トランザクションサービス
７２には、クライアント（たとえばアプリケーション６０）が、トランザクショ
ンを開始するために呼び出し、後に、動作をコミットまたは中断するために呼び
出す、ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎの分散トランザクションコ
ーディネータ（ＭＳＤＴＣ、または単にＭＴＣまたはＤＴＣ）を含めることが
できる。ＤＴＣは、明確に文書化され、短い要約およびＴｘＦ７０に関してそれ
が機能する範囲までを除いて、本明細書では詳細に説明しない。

【００２８】一般に、図３に表されているように、ＭＳＤＴＣでは、ＣＯＭ／ＯＬＥを介
して、アプリケーション６０などのアプリケーションが、トランザクションコー
ディネータ７６（図３）のメソッドすなわち、ＢｅｇｉｎＴｒａｎｓａｃｔｉｏ
ｎメソッドを呼び出すことによって、トランザクションを開始する。トランザク
ションコーディネータ７６は、ネットワーク内のトランザクションサーバまたは
そのローカルプロキシとすることができる。この呼び出しによって、トランザク
ションを表すトランザクションオブジェクト／コンテキスト７８が作成される。
その後、アプリケーション６０は、１つまたは複数のリソースマネージャを呼び
出して、トランザクションの作業を行う。本発明では、ＴｘＦコンポーネント７
０が、トランザクショナルファイルシステム動作に関するリソースマネージャと
して働く。やはり図３に示され、以下で説明されるように、ファイルシステム６
２へのＡＰＩ呼出し（たとえば、ＣｒｅａｔｅＦｉｌｅＥｘ８０および他のフ
ァイルシステム動作）によって、ＴｘＦコンポーネント７０へのコールアウトが
生成される。

【００２９】ファイルシステム６２へのアプリケーションの最初の呼出しで、ファイル、デ
ィレクトリ、またはアプリケーションの現在のスレッド／プロセスが識別され、
これにトランザクションコンテキスト７８を関連付けることができる。トランザ
クションコンテキストが関連付けられる場合に、ファイルシステム６２は、Ｔｘ
Ｆ７０をコールアウトする。ＴｘＦ７０は、トランザクションの代わりの作業を
初めて実行する時に、トランザクションコーディネータ７６を呼び出し、これに
よって、ＴｘＦ７０がこのトランザクションに用いられるリソースマネージャで
あることをトランザクションコーディネータ７６に知らせることによって、トラ
ンザクションに参加する。他のリソースマネージャ８４（たとえばデータベース
コンポーネントの）が、トランザクションに同様に参加することができ、それに
よって、データベースの動作およびファイルシステムの動作を、同一のトランザ
クション内で一緒にコミット（または中断）できることに留意されたい。

【００３０】ＴｘＦ７０が、図３に一般的に示されているように、ＩＴｒａｎｓａｃｔｉｏ
ｎオブジェクト７８と共に来るトランザクション識別子（ＩＤ）を使用して、ト
ランザクションに関する参加を必要とする時を判定するために、ＴｘＦコンポー
ネント７０のトランザクションマネージャ８２レイヤが、トランザクションＩＤ
のトランザクションテーブル８６内で維持される既知の参加しているトランザク
ションに対してＩＤを検査する。既にリストされている場合に、トランザクショ
ンＩＤおよびトランザクション参照が、Ｉ／Ｏ要求パケット（ＩＲＰ）で記録さ
れ、ＩＲＰが継続する。ＮＴＦＳでのＩＲＰの使用は、明確に文書化され、説明
を簡単にするために本明細書では詳細に説明しない。しかし、トランザクション
がテーブル８６にリストされていない場合には、ＴｘＦは、ＴｘＦ７０が、この
トランザクションに関連付けられる必要があるリソースマネージャであることを
トランザクションコーディネータ７６に通知し、参加したトランザクションのテ
ーブル８６にトランザクション識別子を保管する。

【００３１】具体的に言うと、トランザクションが、テーブル８６にリストされていない新
規トランザクションである時に、トランザクションコーディネータ７６への参加
が必要である。このために、ＴｘＦマネージャ８２は、プロキシ８８を使用して
、ＯＬＥトランザクションまたは別のプロトコルを使用してトランザクションコ
ーディネータ７６と通信する。本発明と共に使用するのに適する代替プロトコル
および類似物には、ＸＡ（Ｘ／Ｏｐｅｎの）、ＴＩＰ（Ｔｒａｎｓａｃｔｉｏｎ
ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、および／またはオペレーティングシ
ステム内の固有のトランザクションコントロールが含まれる。ＣｒｅａｔｅＦｉ
ｌｅＥｘ８０要求は、ＩＴｒａｎｓａｃｔｉｏｎオブジェクト７８を（たとえ
ばＤＴＣのＩｔｒａｎｓａｃｔｉｏｎＴｒａｎｓｍｉｔｔｅｒメソッドを介して
）バイトのフラットコレクションにマーシャリングする。参加が必要な場合には
、これらのバイトが、プロキシ８８に送られ、プロキシ８８は、ＤＴＣのＩＴｒ
ａｎｓａｃｔｉｏｎＲｅｃｅｉｖｅｒメソッドを呼び出して、参加に必要なＩＴ
ｒａｎｓａｃｔｉｏｎオブジェクト７８を取り戻す。プロキシ８８は、ＤＴＣオ
ブジェクトＩＴｒａｎｓａｃｔｉｏｎＲｅｓｏｕｒｃｅＡｓｙｎｃおよびＩＴｒ
ａｎｓａｃｔｉｏｎＥｎｌｉｓｔｍｅｎｔＡｓｙｎｃを維持する。ＩＴｒａｎｓ
ａｃｔｉｏｎＲｅｓｏｕｒｃｅＡｓｙｎｃは、トランザクションコーディネータ
７６が２フェーズコミットを駆動するために呼び出すＴｘＦコールバックルーチ
ンを実装し、参加呼出しと共に供給される。ＩｔｒａｎｓａｃｔｉｏｎＥｎｌｉ
ｓｔｍｅｎｔＡｓｙｎｃは、ＩＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：：ｅｎｌｉｓ
ｔ（）によって返され、これには、２フェーズコミットコントロールの確認のた
めにＴｘＦ７０が呼び出すメソッドが含まれる。プロキシ８８は、Ｉｔｒａｎｓ
ａｃｔｉｏｎＲｅｓｏｕｒｃｅＡｓｙｎｃおよびＩｔｒａｎｓａｃｔｉｏｎＥｎ
ｌｉｓｔｍｅｎｔＡｓｙｎｃのメソッドと、ＴｘＦコンポーネント８２とプロキ
シ８８との間の通信に関するファイルシステムコントロール（ＦＳＣＴＬ）ベー
スのリモートプロシージャコール（ＲＰＣ）との間の仲介物として働く。

【００３２】ＴｘＦコーディネータプロキシに、ＤＴＣコーディネータプロセスと同一のプ
ロセスで動作させることが実行可能であり、トランザクションマネージャをカー
ネル内に移動し、これによってプロセス切換えのオーバーヘッドを除去すること
も実行可能であることに留意されたい。ＤＴＣプロキシスタブをカーネル内に移
動して、ユーザモードプロキシを作成する際のＴｘＦ作業の必要をなくし、これ
と同時に、ＴｘＦプロキシからトランザクションマネージャへの余分なプロセス
切換えを除去することもできる。ＴｘＦプロキシは、ＴｘＦプロキシによる作業
を必要とするＤＴＣコーディネータと同一プロセス内で動作することができるが
、これは、前の解決策と同数のプロセス切換えを有することになる。

【００３３】参加の後に、トランザクションが進行する際に、トランザクションコーディネ
ータ７６は、トランザクションに参加したＴｘＦ７０（および、おそらくは、他
のＴｘＦまたはデータベースリソースマネージャなど、他のリソースマネージャ
８４）を含むリソースマネージャのそれぞれを記憶する。これによって、ファイ
ルシステム情報もコミットするトランザクションの一部として、他の情報（たと
えばデータベース情報）をコミットできるようになり、また、複数のトランザク
ション対応ファイルシステム（たとえばリモートマシン上の）ファイルを、同一
のトランザクションの一部としてコミットできるようになることに留意されたい
。

【００３４】通常、アプリケーション６０は、トランザクションをコミットするためにトラ
ンザクションコーディネータ７６のＣｏｍｍｉｔトランザクションメソッドを（
ＣＯＭを介して）呼び出すことによって、トランザクションを完了する。トラン
ザクションコーディネータ７６は、２フェーズコミットプロトコルをすべて実行
して、参加したリソースマネージャのそれぞれにコミットさせる。２フェーズコ
ミットプロトコルによって、すべてのリソースマネージャがトランザクションを
コミットするか、または中断することが保証される。第１フェーズで、トランザ
クションコーディネータ７６が、ＴｘＦコンポーネント７０を含むリソースマネ
ージャのそれぞれに、コミットの準備ができているかどうかを尋ねる。リソース
マネージャが肯定的に応答する場合に、第２フェーズで、トランザクションコー
ディネータ７６が、リソースマネージャにコミットメッセージをブロードキャス
トする。リソースマネージャのどれかが否定的に応答するか、または準備要求に
応答できない場合、および／またはトランザクションの一部で障害が発生する場
合に、トランザクションコーディネータ７６は、トランザクションが中断するこ
とをリソースマネージャに通知する。また、アプリケーションが完了できない場
合に、アプリケーション６０が、Ａｂｏｒｔトランザクションメソッドを呼び出
す。アプリケーションに障害が発生した場合には、トランザクションコーディネ
ータ７６が、アプリケーションの代わりにトランザクションを中断する。その後
、ＴｘＦ７０を含むさまざまなリソースマネージャが、以下で説明するように、
部分的なアクションを元に戻す。

【００３５】したがって、ＴｘＦコンポーネント７０は、標準トランザクションサービス（
ＤＴＣなど）に関してリソースマネージャとして働き、これによって、真のユー
ザ定義トランザクションサポートが、ファイルシステムに拡張される。ＮＴＦＳ
を用いると、以下で説明するように、ＴｘＦが、過渡的なファイルごとおよびス
トリームごとのトランザクション状態を普通のＮＴＦＳ構造体にリンクできるよ
うになることに留意されたい。

【００３６】本発明の一態様によれば、アプリケーション６０は、トランザクションにファ
イルシステム動作を含めることを選択することができる。これは、ファイルが被
トランザクションとしてマークされ、それに対する動作がトランザクショナルに
実行されるようにファイルごとに、または、スレッド／プロセスが被トランザク
ションとしてマークされ、そのスレッド／プロセスによって行われる動作がトラ
ンザクショナルに実行されるスレッド／プロセスごとに、達成することができる
。

【００３７】トランザクションにファイルを含めるために、ＣｒｅａｔｅＦｉｌｅＷＩＮ
３２ＡＰＩの変形であるＣｒｅａｔｅＦｉｌｅＥｘアプリケーションプログラ
ミングインターフェース（ＡＰＩ）呼出し（以下で説明する）と共に使用するこ
とができる被トランザクションモードフラグ（たとえばビット）を定義する。こ
のフラグがセットされている時に、本発明のシステムは、このファイルを自動的
にトランザクションコンテキストに含める。この目的のために、図３に一般的に
示されているように、作成要求８０がＩ／Ｏ要求パケット（ＩＲＰ）を介してフ
ァイルシステム（ＮＴＦＳ）６２に来る時に、既存のトランザクションコンテキ
スト７８を、そのコンテキスト７８にポインタを渡すことによって要求にアタッ
チすることができ、これによって、ファイルを、既存のトランザクションコンテ
キスト７８の一部として作成／オープンできるようになる。その代わりに、Ｃｒ
ｅａｔｅＦｉｌｅＥｘＡＰＩ呼出しのＩｔｒａｎｓａｃｔｉｏｎポインタへの
ポインタがＮＵＬＬである場合に、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｔｒａｎｓ
ａｃｔｉｏｎＳｅｒｖｅｒ（ＭＴＳ）／コンポーネントオブジェクトモデル（
ＣＯＭ）のように、コンテキストがスレッドから自動的に選択される。成功裡の
作成／オープン要求８０に応答して返されるファイルハンドル９０に、トランザ
クションコンテキスト７８へのポインタが含まれる。その後、そのハンドル９０
を用いて行われる呼出しは、ポインタを介して、トランザクションコンテキスト
を関連付けられているものとして認識され、そのトランザクションコンテキスト
から関連するトランザクションが識別され、そのハンドルを使用するファイルシ
ステム動作が、トランザクションが終了されるまでトランザクションの代わりに
実行される。

【００３８】ＣｒｅａｔｅＦｉｌｅＥｘＡＰＩは、既存のＣｒｅａｔｅＦｉｌｅＷｉｎ
３２ＡＰＩの適当なスーパーセットであり、トランザクションモードをセット
するためのフラグ「ＦＩＬＥ＿ＦＬＡＧ＿ＴＲＡＮＳＡＣＴＥＤ」をとる「ｄｗ
ＡｄｄｉｔｉｏｎａｌＦｌａｇｓ」ＤＷＯＲＤパラメータが追加されている。ま
た、トランザクションコンテキストオブジェクトをポイントすることができるパ
ラメータ、ＬＰＵＮＫＮＯＷＮｐｕｎｋＴｒａｎｓａｃｔｉｏｎも定義され、
これがＮＵＬＬの場合には、上で説明したように、オブジェクトが現在のＭＴＳ
／ＣＯＭコンテキストから選択される。

【００３９】スレッド／プロセスを被トランザクションとしてマークするために、ＳｅｔＴ
ｒａｎｓａｃｔｅｄＦｉｌｅｓＡＰＩが設けられ、このＡＰＩでは、Ｃｒｅａ
ｔｅＦｉｌｅ／ＣｒｅａｔｅＦｉｌｅＥｘ呼出しの組を、効果的にそれらが被ト
ランザクションモードフラグをセットされているかのように扱う。特定のＣｒｅ
ａｔｅＦｉｌｅＥｘが、ヌルでないＩＴｒａｎｓａｃｔｉｏｎオブジェクトポイ
ンタを指定する場合には、そのオブジェクトが、トランザクションコンテキスト
７８に使用され、そうでない場合には、ＭＴＳトランザクションオブジェクトが
、スレッドから選択される。

【００４０】ＳｅｔＴｒａｎｓａｃｔｅｄＦｉｌｅｓＡＰＩは、スレッド／プロセスを被
トランザクションとしてマークし、これによって、そのスレッド／プロセスを介
するすべてのファイルシステムアクセスをトランザクション処理するのに使用さ
れる。３つの異なるフラグをセットすることができる、すなわち、セットされた
時に、現在のスレッドからのすべてのファイルシステムアクセスをトランザクシ
ョン処理されるようにするフラグと、セットされた時に、現在のプロセス内のス
レッドのそれぞれからのすべてのファイルシステムアクセスをトランザクション
処理されるようにするフラグと、セットされた時に、現在のプロセスから作成さ
れた子プロセスがこれらのフラグのうちの第２および第３をセットされるように
するフラグである。したがって、スレッド／プロセスを、作成されるプロセスが
このモードを継承する形でマークすることが可能であり、これは、既存のアプリ
ケーションがトランザクション処理されるＮＴＦＳを利用できるようになるので
、非常に強力な機構である。さらに、これによって、アプリケーションが、被ト
ランザクションモードビットを有しない、ｄｅｌｅｔｅＦｉｌｅおよびｃｏｐｙ
Ｆｉｌｅなどのファイルシステム動作を行えるようになる。この特徴は、トラン
ザクション処理されるコマンドラインバッチスクリプトを可能にするに使用する
こともできる。以下で、ＳｅｔＴｒａｎｓａｃｔｅｄＦｉｌｅｓＡＰＩを説明
する。

【００４１】 SetTransactedFiles( [in] DWORD dwMode, // 列挙型TxFILEMODEからの０または１個以上の値。 // この値には、dwMaskパラメータによって // 示される、セットされるフラグの新しい // 設定が含まれる。 [in] DWORD dwMask, // 列挙型TxFILEMODEからの０または１個以上の値。 // このマスクに存在するフラグの値だけが、 // SetTransactedFiles呼出しによって影響 // を受ける。 [out] DWORD* pdwPrevMode // オプション。与えられた場合に、 // ここを介して、前のモードが呼出し元に // 返される。 );

【００４２】正しいフラグ値は、次の通りである。 Enum TxFILEMODE { TxFILEMODE_THISTHREAD = 0x00000001, // 現在のスレッド TxFILEMODE_ALLTHREADS = 0x00000002, // プロセス内のすべて // のスレッド TxFILEMODE_CHILDPROCESSES = 0x00000004, // このモードがセッ // トされている間に現 // 在のプロセスから作 // 成されるすべての子 // プロセスが、自動的 // に_ALLTHREADSおよ // び_CHILDPROCESSES // をセットされるよう // にする TxFILEMODE_ALL = 0xFFFFFFF };

【００４３】図４に示されているように、作成／オープン以外のファイル動作について、ア
プリケーション６０は、たとえばファイル読取動作を要求するＡＰＩ呼出し９２
を介して、ハンドル９０をファイルシステムに供給し、これによって、その中の
トランザクションコンテキストポインタを介して、ファイルシステムが、トラン
ザクションコンテキストを突き止めることができる。上で説明したように、Ｔｘ
Ｆ７０がトランザクションに参加しなければならない場合があることに留意され
たい。ファイルハンドル９０内でポイントされるトランザクションコンテキスト
のゆえに、ファイルシステムは、この動作がトランザクションに含まれることな
らびに特定の関連するトランザクションの識別子を知る。トランザクションコン
テキストにファイルを含めることは、読取、書込、ファイル作成、および削除を
含むファイルに対する動作がトランザクション処理されることを意味する。任意
の数のファイルシステム要求を、単一のトランザクション内でグループ化し、原
子的で耐久性がある形でコミットまたは中断することができる。さらに、どの瞬
間でも、任意の数のトランザクションを進行中にすることができ、各トランザク
ションはお互いから分離される。

【００４４】トランザクショナルアクセス−読取および書込の分離上で説明したように、トランザクション処理されるアクセスに関してファイル
をオープンまたは作成することができる。現在、率直で安全で予測可能な挙動を
もたらすために、このシステムでは、システム内のアップデータ（ライタ）トラ
ンザクションの数を、すべての所与の時刻に１つに制限する、すなわち、複数の
トランザクションが読取／書込（ＲＷ）アクセスのためにファイルを同時にオー
プンすることを試みる場合に、ファイルオープンの時にエラーが返される。した
がって、これらの制約は、（ストリームレベルではなく）ファイルレベルに置か
れる。この制約は、ファイルのコミットまたは中断まで、ファイルと共にとどま
る。

【００４５】しかし、より微細な粒度を有するシステムを実施することが、代替案として実
行可能であり、たとえば、ファイルを複数のライタがオープンすることができる
が、どのライタも、ファイル内の別のライタが書き込んだ（ダーティ）ページを
上書きできない、すなわち、ページがダーティになった後に、そのページがロッ
クされる。また、「ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ（最後のライタが有効）
」タイプのアクセスを、ここで実施することができる。これらのタイプのファイ
ル「書込」アクセスが、所与のシステムで相互排他的でないことに留意されたい
。というのは、あるＡＰＩで、ファイル全体をロックする書込アクセス用にファ
イルをオープンし、もう１つのＡＰＩで、ページ（または他のファイルセクショ
ン）ごとのロックを有する書き込みアクセス用にファイル（その時点でロックさ
れたファイルではない）をオープンし、かつ／またはもう１つのＡＰＩで、ｌａ
ｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ書込アクセスを用いることが可能だからである。
しかし、本明細書では、説明を単純にするために、ファイル全体を、トランザク
ションによる読取／書込アクセスのために所与の時に１回だけオープンできる（
すなわち、他のアクセスがシリアライズされる）ものとして本発明を説明する。
ファイルの非トランザクショナルアップデータも、書込用のトランザクショナル
オープンを用いてシリアライズされる。これによって、同一のトランザクション
に属する複数のスレッドが書込のために同時にファイルをオープンできなくなる
のではないことに留意されたい。ファイルをオープンできるリーダーすなわち読
取専用アクセスを用いるリーダーの数に対する重要な制限はない。

【００４６】本発明によれば、読取アクセスのためにあるトランザクションによってオープ
ンされるファイルは、ライタがリーダーの前と後のどちらにファイルをオープン
したかに無関係に、別のトランザクションによってファイルに対して行われる同
時変更から分離される。さらに、ファイルを変更したトランザクションがそのト
ランザクションをコミットするかどうかに無関係に、分離は、読取専用トランザ
クションのアクセスが終了するまで継続される。たとえば、図５に示されている
ように、図５でタイムラインの先頭のＸ／ＲＯによって表される、読取専用アク
セスのためにページのファイルＶ_０をオープンするトランザクショナルリーダー
Ｘを検討されたい。ファイル内の各ページの大文字の「Ｏ」は、オープンの時の
元のデータを表すことに留意されたい。ライタＹが、後に、別のトランザクショ
ンで読取／書込アクセスのためにファイルＶ_１をオープンし（Ｙ／ＲＷ）、それ
に対する変更を行う（Ｙ／書込）場合に、トランザクショナルリーダーＸは、ラ
イタＹのＶ_１での変更ではなく、ファイルＶ_０の元のデータを見続ける。非トラ
ンザクションが、変更の際にファイル変更を見ることに留意されたい。

【００４７】以下で説明するトランザクショナル分離を達成するために、ファイルの「バー
ジョン」Ｖ_０が、（少なくとも）リーダーＸがそのファイルをオープンしている
時間、リーダーＸのために保持される。これは、トランザクショナルライタＹが
コミットした場合であってもそのままである。ライタＹが、ファイル自体に変更
を加え、リーダーＸによって見られるバージョンが、以下で詳細に説明するよう
に、変更が書き込まれる前に作られた元のデータのページごとのコピーであるが
、その逆すなわち、リーダーＸのために元のファイルを未変更のままに保ち、ラ
イタＹのために変更されたページのバージョンを保持することが実現可能である
ことに留意されたい。また、本明細書で使用される用語「バージョン」、「バー
ジョン管理される」、「バージョン管理」および類似物が、タイムスナップショ
ットの１点を指す（ソースコード管理システムなどの永続的バージョン管理と混
同してはならない）ことに留意されたい。さらに、トランザクショナルリーダー
を、非トランザクショナルライタとシリアライズして、実装を容易にすることが
できることに留意されたい。その代わりに、非トランザクショナルライタを、分
離だけの目的で「システム所有」トランザクションに含めることができる。した
がって、予測可能なトランザクショナル読取セマンティクスがもたらされ、これ
によって、被トランザクションリーダーが、所与の時点のファイルの「凍結され
た」イメージに頼ることができる。

【００４８】図５に戻って、トランザクショナルライタＹが、ファイルＶ_１をコミットした
後に、トランザクショナルライタＺが、図９に示されているように、読取−書込
アクセスのためにファイルＶ_２（Ｖ_１から変更されていない）をオープンする（
Ｚ／ＲＷ）ことができる。ライタＺは、ライタＹのコミットした変更を見、さら
にそれを変更することができる（Ｚ書込）。しかし、この時に、リーダーＸが
、このファイルがＸによって最初にオープンされた時にＸが見た元のファイルペ
ージを見続け、Ｙがコミットした変更を一切見ないことに留意されたい。リーダ
ーＸがファイルをクローズし、再オープンする場合に限って、リーダーＸが、お
そらくＹの変更を見る。リーダーＸは、図５に示されているように、リーダーＸ
がファイルをクローズし、Ｚがコミットした後にファイルＶ_２を再オープンする
ならば、ライタＺのコミットした変更も見ることができる。言い換えると、リー
ダーＸは、Ｚがコミットする前にクローズし、再オープンする場合には、バージ
ョンＶ_１を見るが、リーダーＸが、Ｚがコミットした後でクローズし、再オープ
ンする場合には、ファイルバージョンＶ_２を見る。以下で説明するように、その
代わりに、オープンの時に最新のコミットされたバージョンより古いバージョン
を維持し、そのオープンを可能にすることが実現可能である。

【００４９】これらのセマンティクスが、既存のファイル共有モードを使用して表現可能で
はないことに留意されたい。本明細書に記載のトランザクション分離セマンティ
クスでは、ハンドルをお互いに分離するファイル共有モードと異なって、トラン
ザクションの効果をお互いに分離する。既存のファイル共有モードは、変更され
ず、追加のシリアライゼーションに使用することができる。たとえば、「書込拒
否」ファイル共有モードを指定する、同一のトランザクションの２つの異なるス
レッドによるトランザクショナル更新のためのオープンの場合に、第２のオープ
ンが、共有違反によって拒否される。これによって、分散アプリケーションが、
複数のスレッド、プロセス、またはコンピュータにトランザクション作業負荷を
割り当てられるようになると同時に、トランザクションによって行われる変更が
、他のトランザクションまたは非トランザクションワーカーから保護される。さ
らに、これらのセマンティクスでは、各リーダーが、オープンされながら安定し
た状態を保つためにファイルの内容に頼ることができる予測可能なバージョン管
理された読取が保証される。

【００５０】下に示す互換性マトリックスで、「はい」は、モードが追加のトランザクショ
ナル制約に関する互換性を有することを意味する。

【００５１】

【表１】

【００５２】したがって、更新するトランザクションは、その変更を含むファイルの最新の
バージョンを見るが、被トランザクション読取では、ファイルのコミットされた
バージョンが得られる。１つの代替案（上で一般的に説明したもの）が、オープ
ンの時点でファイルの最新のコミットされたバージョンを提供し、トランザクシ
ョナル読取のためにオープンされている間は、さらに変更が行われ、コミットさ
れる際に、バージョンの変更を許可しないことである。これの長所は、リーダー
が、オープンの期間中に、データのトランザクショナルに一貫性のあるビューを
見るようになることである。

【００５３】第２の代替案では、リーダーが見るバージョンを、最初のファイルシステムア
クセス時または他のより早い時（すなわち、ＴｘＦログでのより早い点）でのバ
ージョンとすることができる。これによって、このリーダーが開始された時の最
も最近にコミットされたバージョンを提供することができる。この開始の時は、
トランザクションが最初にシステム内のＮＴＦＳオブジェクトにアクセスした時
とすることができ、あるいは、その代わりに、この時を、統合されたシナリオで
他のＡＰＩを使用して定義することができる（たとえば、ログシーケンス番号ま
たはＬＳＮを使用する）。この特徴の長所は、トランザクションが、複数のファ
イルにまたがってある時点のスナップショットを得ることであり、これは、複数
のファイル依存性およびリンクがある時（たとえばＨＴＭＬファイルまたはＸＭ
Ｌファイル）に有用になる可能性がある。この代替案では、同一トランザクショ
ン内の１つのファイルの複数のオープンが、そのトランザクション内の最初のオ
ープン時に選択されたバージョンを得ることができることに留意されたい。しか
し、諒解できるように、システムによって維持される必要があるバージョンヒス
トリの量は、この第２の代替案で増加する。

【００５４】用語「バージョンウィンドウ」は、その間に、選択されたバージョン管理法式
をサポートするために、前にコミットされたバージョンの組が維持される時間隔
を指す。上で説明した第１の代替案では、バージョンウィンドウが、各ファイル
によって変化し、まだアクティブであるファイルの最も古いオープンから現在の
時刻までの間の時間である。第２の方式では、ウィンドウは、システム内の最も
古いトランザクションの開始ＬＳＮから現在の時刻までの時間として定義される
。これらの方式の一方または両方をサポートすることができ、バージョンを維持
するためにＴｘＦ７０によって行われる作業は、本質的に同一である。説明を単
純にするために、本発明を、本明細書では主に第１の方式に関して説明するが、
この場合、リーダーが見るバージョンは、トランザクションでの最初のオープン
の時点でのファイルの最も最近にコミットされたバージョンである。したがって
、この第１の方式では、ストリームバージョンがオープン時に決定されるので、
アプリケーションは、最新のコミットされたデータを望む場合に、ハンドルをク
ローズし、再オープンする必要がある。これは、ウェブサーバのシナリオに特に
関係する可能性が高く、この場合には、ウェブサイトを、トランザクショナルに
オンラインで更新することができ、したがって、リーダーは、新たにコミットさ
れた状態を見るために、ハンドルをクローズし、再オープンする必要がある。

【００５５】一実施形態では、変更が最終的にライタによってコミットされると仮定される
ので、ファイルへの書込が、実際のファイルに対する書込である。コミットされ
ない場合には、すべての変更が、以下で説明するように、ログに取り込まれたア
ンドゥ情報を介してロールバックされる。したがって、バージョン分離をもたら
すために、ページに向けられた各書込は、まず、古いページがトランザクショナ
ルリーダーのために保存されることをもたらす。しかし、これを逆に行うこと、
すなわち、変更がコミットされるまで元のファイルを手付かずで残し、これによ
って、リーダーではなくライタが、それのために新しいページを作成されるよう
にすることが可能である。

【００５６】ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）２０００（またはＮＴ（登
録商標））オペレーティングシステムを使用する好ましい実施形態では、古いバ
ージョンのためにディスクに別のファイルを作成するのではなく、キャッシュマ
ネージャおよび仮想メモリマネージャまたはＶＭＭの観点から、別のインメモリ
ストリームを提示する。キャッシュマネージャ、ＶＭＭ、および非トランザクシ
ョナルＮＴＦＳに対するこれらの関係は、参照によって本明細書に組み込まれる
参考文献、「ＩｎｓｉｄｅＷｉｎｄｏｗｓＮＴ（登録商標）」、ｂｙＨｅ
ｌｅｎＣｕｓｔｅｒ、ＭｉｃｒｏｓｏｆｔＰｒｅｓｓ（１９９３）、「Ｉｎ
ｓｉｄｅｔｈｅＷｉｎｄｏｗｓＮＴ（登録商標）ＦｉｌｅＳｙｓｔｅｍ
」、ＨｅｌｅｎＣｕｓｔｅｒＭｉｃｒｏｓｏｆｔＰｒｅｓｓ（１９９４）
、および「ＩｎｓｉｄｅＷｉｎｄｏｗｓＮＴ（登録商標）、Ｓｅｃｏｎｄ
Ｅｄｉｔｉｏｎ」、ｂｙＤａｖｉｄＡ．Ｓｏｌｏｍｏｎ、Ｍｉｃｒｏｓｏｆ
ｔＰｒｅｓｓ（１９９８）に記載されている。

【００５７】トランザクショナルリーダーのためのバージョン維持に関する仮想メモリマネ
ージャおよびキャッシュマネージャの展望からは、ファイルのより古いバージョ
ンの読取が、異なるファイルの読取のように管理される。これによって、アプリ
ケーションが、より古いバージョンを自分のアドレス空間に単純にマッピングで
きるようになり、メモリ記述子リストを使用してデータにアクセスするクライア
ント（たとえばリダイレクタ）が、透過的に動作できるようにもなる。これが可
能であるのは、Ｗｉｎｄｏｗｓ（登録商標）２０００オペレーティングシステム
で、ＶＭＭおよびキャッシュマネージャが、ファイルシステム入出力（Ｉ／Ｏ）
に参加するからである。ファイルシステム（キャッシングされないアクセスのた
めにオープンされたファイルを除く）では、キャッシュマネージャを使用して、
データをシステムメモリにマッピングし、キャッシュマネージャは、ＶＭＭを使
用してＩ／Ｏを開始する。ダーティページ書込は、通常は、バックグラウンドス
レッドで、遅延モードで発生する。このアーキテクチャの結果として、アプリケ
ーションアドレス空間に直接にマッピングされるファイルは、キャッシュマネー
ジャとページを共有し、キャッシュマネージャは、それを得るのにどのシステム
サービスが使用されるかに無関係に、データの一貫性のあるビューを提供する。
その結果、ネットワークリダイレクタ（以下で説明する）が、データをローカル
にキャッシングすると同時に、他のクライアントとの一貫性がある形でサーバの
データを得ることに留意されたい。

【００５８】分離を達成するために、まだ読取中の最も古いコミットされたバージョンから
始めて最後に更新されたバージョンまで、複数のバージョンが維持される。各バ
ージョンは、最新バージョンに対する変更を追跡する、バージョンに関連するデ
ータ構造体を有する。未変更のページが読み取られる場合に、そのページは、フ
ァイル（キャッシュ内にあるかディスクに書き込まれた可能性がある）から読み
取られ、変更されたページが読み取られる場合には、そのページは、変更された
ページデータ（やはりキャッシュ内にある可能性がある）から読み取られる。い
くつかのバージョンが、それを読み取るトランザクションを有しない場合がある
が、それらがバージョンウィンドウ内にあり、将来にオープン要求を受ける可能
性があるので、それらバージョンのインメモリ構造体を維持することができるこ
とに留意されたい。一度もオープンされたことがないバージョンは、データペー
ジを保管するためにメモリを占有しない。最新バージョンは、ベースファイルス
トリームに対応し、更新される可能性がある。

【００５９】図６に示されているように、各バージョンは、ＴｘＦ「バージョンストリーム
制御ブロック」（ＴｘＦＶＳＣＢ）によって記述される。ファイルのバージョン
ストリーム制御ブロックは、時間の順でリスト内でリンクされ、最新以外の各バ
ージョンが、コミット／中断され、読取専用である。最新のバージョンは、コミ
ットされる場合とされない場合がある。

【００６０】各ＴｘＦＶＳＣＢ（たとえば９４）に、ＴｘＦログに記録される、トランザク
ションのコミットＬＳＮが保管されるバージョンログシーケンス番号９６（バー
ジョンＬＳＮ）が含まれる。（最も最近の）コミットされていないバージョンに
ついて、一実施形態で、このＬＳＮが、たとえば現在の時点未満の最高のＬＳＮ
を見つけるのを容易にする、ＴｘＦ定義の「ＭＡＸ＿ＬＳＮ」である。このバー
ジョンより早いコミットされたデータの読取を望むリーダーは、変更テーブル（
たとえば９８_１）内のエントリを使用することによって、それにアクセスするこ
とができ、変更テーブルは、ＴｘＦＶＳＣＢによってポイントされるバージョン
によって変更されたページ番号を記録するインメモリテーブル９８である。Ｔｘ
ＦＶＳＣＢ９４などの各ＴｘＦＶＳＣＢには、このバージョンに対応するセクシ
ョンオブジェクトポインタ（ＳＯＰ）構造体１００も含まれ、これは、キャッシ
ュマネージャおよび仮想メモリマネージャによって使用され、インメモリストリ
ームを表す。状態フラグ１０２も設けられ、そのうちの１つが、バージョンがコ
ミットされたか否かを示す。最も新しいバージョンだけが、未コミットになりえ
ることに留意されたい。やはり含まれるのが、ＶｅｒｓｉｏｎＬｅｎｇｔｈ１０
４データフィールドと変更テーブルポインタフィールド１０６であり、後者には
、このバージョンによって変更されたページ番号を記録する変更テーブル９８へ
のポインタが含まれる。

【００６１】図６に示されているように、変更テーブル（たとえば９８_１）内に、ディスク
アドレスをページ番号に関連して保管して、ディスク上のページの前のバージョ
ンを見つけることができる（このバージョンでページが少なくとも１回書き込ま
れているものとして）。図６からわかるように、主にメモリを節約するために、
ページがディスク上で連続的に保管される場合に、ページ範囲を１エントリに保
管することができる。図７に、ファイルの複数のバージョンに関する変更テーブ
ル９４_０〜９４_３を示す。木構造などの効率的な検索構造を使用して、変更テー
ブルを編成することができる。

【００６２】ファイルが、トランザクション内で読取専用アクセスのためにオープンされる
場合に、適当なコミットされたバージョンが選択される。バージョン番号は、「
ｒｅａｄＬＳＮ」によって識別される。ｒｅａｄＬＳＮは、上で説明したように
、どのタイプのバージョン管理が使用されるかに応じて、現在のＬＳＮまたは古
いＬＳＮのいずれかになる。選択されたバージョンは、ｒｅａｄＬＳＮの前の最
後にコミットされたバージョンである。たとえばバージョンが古すぎるなど、そ
のようなバージョンが存在しない場合には、オープンが失敗する。ファイルが、
ＴｘＦＶＳＣＢを関連付けられていない場合には、新しいＴｘＦＶＳＣＢが、空
の変更テーブルと共に作成され、未コミットとマークされる。デフォルトのイン
メモリストリームが使用され、その結果、既存のキャッシュデータを読取に使用
することができるようになる。書込アクセスの場合、最新のバージョンがコミッ
トされていない場合には、それがそのまま使用されるが、そうではなく、未コミ
ットとマークされていない場合には、新しいＶＳＣＢが作成され、未コミットと
してマークされる。

【００６３】ファイルに書き込む時の分離を容易にするために、データのページ（たとえば
、ユーザレベルバッファ１０８）がトランザクションによって変更されるたびに
、そのページが、本質的にその場で、すなわちキャッシュ１１０（図８）内で編
集される。その後、キャッシュ１１０が、キャッシュマネージャおよび／または
ＶＭＭ１１２によって、適当な時にディスク（または他の適当な不揮発性ストレ
ージメディア）１１４に書き込まれる。上で一般的に説明したように、データは
、ファイルをメモリ内でマッピングすることまたは書込ＡＰＩを使用することの
いずれかによって、変更することができる。書込ＡＰＩを使用する時には、通常
は、キャッシュマネージャ１１２が、変更をメモリ常駐ページ１１６にコピーす
るのに使用される。キャッシュマネージャ１１２が、ファイルをシステムメモリ
内にマッピングするのに使用されることに留意されたい。メモリマッピングが使
用される時には、変更は、アプリケーションによってシステムメモリページ（た
とえばページ１１６）に対して直接に行われ、このページは、キャッシュマネー
ジャ１１２がマッピングしたページと同一である。変更は、「ダーティ」ビット
を介して記録され、このビットは、メモリマッピングされたＩ／Ｏの場合にプロ
セスプライベートなページテーブルエントリ（ＰＴＥ）１１８に変更が存在する
ことを示す。通常、これらのビットは、メモリマネージャがプロセスのワーキン
グセットからページをトリミングする時に、共有（ページフレーム番号）ＰＦＮ
構造体１２０に伝搬される。これらのビットは、アプリケーション６０によって
、システムＡＰＩを使用してマッピングされたセクションをフラッシュすること
によって、明示的に伝搬することもできる。ダーティページが、バックグラウン
ドで周期的に書き出される可能性もあることに留意されたい。

【００６４】メモリマッピングされた変更がトランザクションに含まれることを保証するた
めに、システムは、各アプリケーションがマッピングしたセクションの仮想アド
レス範囲をコミット時にフラッシュする。このフラッシュは、それをマッピング
したアプリケーションのコンテキスト内から開始される。アプリケーションによ
って明示的にフラッシュされたページだけがトランザクションに含まれるように
するトランザクショナルセマンティクスを定義することができる（たとえば、ユ
ーザセクション内のバイトへの個々の修正ではなく、フラッシュをトランザクシ
ョナルにする）。その代わりに、セクションをマッピングし、フラッシュを行う
プロセスにアタッチ（ＫｅＡｔｔａｃｈＰｒｏｃｅｓｓ）されるシステムスレッ
ドを介してこれを達成することができる。セクションのリストは、対応するトラ
ンザクションテーブルエントリ内で維持される。ファイルＡＰＩによって行われ
た変更も、コミット時にディスクにフラッシュされる必要があることに留意され
たい。これは、ページング書込の時に、前のトランザクションから残っているダ
ーティページ書込と、現在のトランザクションでメモリマッピングによって行わ
れた変更とを区別することが不可能だからである。

【００６５】したがって、ＴｘＦは、トランザクションによる読取専用および読取／書込の
両方のファイルオープンをサポートする。トランザクションが、現在他のトラン
ザクションによってオープンされていないファイルを、読取専用アクセスを用い
てオープンする時に、そのファイルに関するセマンティクスは、非トランザクシ
ョナルオープンと同一である。トランザクションが、読取／書込のためにファイ
ルをオープンする場合には、ＴｘＦが、図９に示されているように、トランザク
ションごとのコンテキストを保管するために、ファイルに関して１つ、ストリー
ムごとに１つ、ストリームバージョンごとに１つの構造体を必要とする。このオ
ープンに関するデータ構造体を、図９に示すが、図９では、「ファイルオブジェ
クト」が、ユーザのファイルハンドルによってマッピングされたオブジェクトで
あり、「ＦＣＢ」が、ＮＴＦＳファイル制御ブロックであり、「ＳＣＢ」が、オ
ープンされた指定されたストリームのＮＴＦＳストリーム制御ブロックであり、
「ＮＰＳＣＢ」が、主にファイルマッピング用のセクションオブジェクトポイ
ンタを保持するのに使用される非ページングストリーム制御ブロックであり、「
ＣＣＢ」が、ＦｉｌｅＯｂｊｅｃｔごとのコンテキスト構造体である。ＴｘＦＦ
Ｏ内のフラグが、ファイルがトランザクションによって読取についてオープンさ
れた時を示すことに留意されたい。

【００６６】図９では、ＴｘＦＣＢ構造体が、ＴｘＦによって維持されるファイルごとの変
更のアンドゥデータのアンカであり、ＴｘＦＣＢ構造体に、トランザクションへ
の参照も含まれる。ＴｘＦＳＣＢは、ストリームバージョンのアンカであり、Ｔ
ｘＦＶＳＣＢは、ストリームの特定のバージョンのアンドゥデータのアンカであ
る。ＴｘＦＯ構造体は、ストリームのバージョンへの特定のトランザクションの
アクセスを記述し、そのバージョンの関係する共有ＴｘＦ構造体へのポインタを
取り込む。

【００６７】図１０に示されているように、第２のトランザクションｔ３が、前の読取専用
トランザクションが終了する前に読取／書込のためにファイルをオープンする場
合に、ファイルの古いバージョンが、本質的にシフト（図１０では右に）されて
、新しいバージョンを表す構造体の余地が作られる。したがって、図１０は、フ
ァイルの現在のバージョンを変更するトランザクションｔ３による１つの読取／
書込オープンと、ファイルの最も最近にコミットされたバージョンにアクセスす
るトランザクションｔ２による読取専用オープンと、前にコミットされたバージ
ョンにアクセスするトランザクションｔ１によるもう１つの読取専用オープンを
表す。単純にするために、各ＦｉｌｅＯｂｊｅｃｔが同一のＳＣＢをポイントし
、これによって、ＮＴＦＳがファイルバージョンを意識しないことに留意された
い。また、各ＦｉｌｅＯｂｊｅｃｔが、一意のページングされないＳＣＢ内にセ
クションオブジェクトポインタのそれ自体の組を有する。普通は、ユーザが実際
にストリームをマッピングしない限り、読取専用トランザクションのセクション
オブジェクトポインタが使用されないことに留意されたい。キャッシングされる
アクセスは、未変更のページの現在のストリームと、変更されたページのログフ
ァイルからサービスされる。各ファイルオブジェクトのＴｘＦＯは、効果的に、
トランザクションがアクセスしているファイルのバージョンを取り込む。

【００６８】一般に、ＴｘＦトランザクションが、ＮＴＦＳハンドルと独立の寿命を有する
ので、ＴｘＦ構造体は、ＮＴＦＳ構造体と独立の寿命を有する。両方が存在する
時には、これらが、図９〜１０に示されているように一緒にリンクされ、ここで
は、単一方向のリンクが、両側での明確に定義されたインターフェースを使用し
てセットアップされる。たとえば、ファイルへの被トランザクションアクセスが
発生する時に、ＴｘＦＣＢへのＦＣＢリンクが検査される。ＮＵＬＬの場合には
、ＴｘＦルーチンを使用してＴｘＦＣＢがセットアップされる。しかし、ＴｘＦ
ＣＢが既に存在する場合には、ＴｘＦファイルテーブルからＴｘＦによってファ
イルＩｄを使用してルックアップされ、そうでない場合には新しいＴｘＦＣＢが
割り振られる。同様に、ＦＣＢが割振り解除され、ＴｘＦＣＢリンクがＮＵＬＬ
でない時には、単一方向（ＮＴＦＳからＴｘＦへの）リンク削除のためにＴｘＦ
ルーチンが呼び出される。

【００６９】ファイルに関するＴｘＦ構造体は、被トランザクションリーダーがファイルを
オープンしていない時、または将来にそのファイルのそのバージョンをオープン
できない時に、割振り解除される。ディレクトリは、ＮＴＦＳディレクトリがデ
ィレクトリ自体の削除に起因してなくなる（再帰的削除で発生する）場合であっ
ても、ＴｘＦＳＣＢ構造体に名前空間分離情報がある限り、維持される。ＴｘＦ
構造体の寿命は、参照カウントを介して管理される。

【００７０】ログ記録サービス本発明のもう１つの態様によれば、一般的に以下で説明するように、永続的状
態のログ記録および回復のために、ＴｘＦ７０は、ログ記録サービス７４（図２
）を使用し、ログ記録サービス７４は、長時間動作するトランザクションをサポ
ートするために、普通のＮＴＦＳログだけに頼るのではなく、複数レベルのログ
記録を可能にする。以下で明白になるように、これによって、多数の利益がもた
らされる。たとえば、通常のＮＴＦＳログは、サイズにおいて４メガバイト程度
であり、これは、現在は短期間のメタデータログ記録に適当であるが、通常のユ
ーザ定義トランザクションは、そのようなログを素早く使い果たす。また、ログ
記録されるＴｘＦトランザクショナル動作の数に対して相対的に多数のログ記録
されるＮＴＦＳ動作がある可能性が高い。さらに、ＮＴＦＳメタデータコミット
動作は、ディレクトリをロックアップし、これによって、長時間を要するＴｘＦ
トランザクションが、ファイルシステムの性能に悪影響を及ぼす（単一レベルロ
グ記録方式を仮定した場合）。

【００７１】従来ののＮＴＦＳログは、明確に文書化されており、したがって、短い要約と
本発明のトランザクショナルファイルシステムと共に使用される範囲を除いて、
本明細書では詳細に説明しない。ＮＴＦＳは、ＮＴＦＳが変更を行う前に、ＮＴ
ＦＳに対するファイルシステム動作のアンドゥレコードおよび／またはやり直す
レコードを書き込むことによって、ファイルシステム動作の中断／クラッシュ回
復を提供する。ＮＴＦＳログは、ファイル作成コマンド、名前の変更など、ＮＴ
ＦＳデータ構造を変更する動作を含む、ＮＴＦＳボリュームに影響する動作を記
録する、ボリュームごとのファイルである。たとえば書き込まれたバイトなどの
ユーザファイルデータではなく、メタデータがログ記録されることに留意された
い。ログは、ファイルとして維持され、システム障害からの回復のためにアクセ
スされる、すなわち、システムがクラッシュした場合に、部分的に完了した動作
を、周知の技法を使用して元に戻すかやり直すことができる。ＮＴＦＳは、耐久
性を提供しない、すなわち、ＮＴＦＳは、コミット時にそのログを強制しない。

【００７２】本発明の一態様によれば、ＴｘＦトランザクションおよび回復管理は、複数レ
ベル回復機構内で、ＮＴＦＳの上に階層化される。上で説明したように、ＴｘＦ
は、ＮＴＦＳ動作を下位コンポーネントとして扱って、ユーザレベルトランザク
ションを構築する。回復に関して、ＴｘＦは、より上位のログを維持し、ログ記
録されたＮＴＦＳ動作を、ＴｘＦが「データ」の前のそれ自体のＴｘＦログを強
制するという意味で、より上位のログに関する「データ」として扱う。この場合
の「データ」は、ＮＴＦＳログであり、回復可能ストア自体である。

【００７３】複数レベルログ記録を達成するために、図１１に一般的に示されているように
、より下位のＮＴＦＳログ１２６の前へのより上位のＴｘＦログ１２４の強制は
、既に使用可能なＮＴＦＳ６４の回復可能性を利用する形での各ログのＬＳＮ（
本明細書ではＴｘＦＬＳＮおよびＮＴＦＳＬＳＮと称する）の調整を介して
達成される。ＮＴＦＳトランザクションによって管理されないデータ（すなわち
、ストリームバイト自体）について、ＴｘＦ７０は、本質的に、以下で説明する
ように、回復可能性を完全に管理する。

【００７４】より上位のＴｘＦログ１２４が、その「データ」すなわちＮＴＦＳログ１２６
のレコードの前に強制される（ＴｘＦログをすべてのＮＴＦＳ動作の前に非効率
的に強制せずに）ことを保証するために、ＮＴＦＳ６４がそのログ１２６にデー
タを強制しようとするたびにＮＴＦＳ６４が呼び出すＴｘＦコールバックが提供
される。この呼出しでは、ＮＴＦＳ６４が、フラッシュされようとしている最高
のＮＴＦＳＬＳＮを示す。それと同時に、ＴｘＦ７０は、ＮＴＦＳコミットＬ
ＳＮを各々のＴｘＦＬＳＮにマッピングするために、ＴｘＦが使用した最近の
ＮＴＦＳトランザクションのマップ１２８を維持する。ＴｘＦがＮＴＦＳコミッ
トＬＳＮの知識を有するように、名前空間変更動作が設計されることに留意され
たい。ＮＴＦＳログは、比較的低い頻度でディスクにフラッシュされるという点
で、耐久性がない。その結果、適度な数のＴｘＦレコードが、ログバッファ内に
存在し、単一のＩ／Ｏ動作で一緒にディスクにフラッシュされる可能性が高い。

【００７５】コールバックに応答して、ＴｘＦ７０は、ＮＴＦＳログで強制されている最高
のＮＴＦＳコミット−ＬＳＮに対応するＴｘＦレコードまで、ＴｘＦログ１２４
を強制する。しかし、この最高のレコードまでのＴｘＦログ１２４のフラッシュ
が、より最適であるに過ぎないことに留意されたい。というのは、より上位のロ
グが先にフラッシュされることを保証する他の方法（たとえば、ＮＴＦＳがその
ログをフラッシュしようとしている時に、いつでも新しいＴｘＦレコードのすべ
てをフラッシュする）で十分であるからである。回復中に、ＴｘＦがその回復を
開始できるようになる前に、ＮＴＦＳが、その回復を完了する。

【００７６】これによって、ＴｘＦログ１２４がＮＴＦＳログ１２６の前にフラッシュされ
るようになるが、ＴｘＦログの末尾付近の一部のログレコードが、ＮＴＦＳによ
ってコミットされないＮＴＦＳ動作を実行した場合があり、そのようなレコード
が、コミットされたレコードに混ざっている可能性がある。対応するＮＴＦＳ動
作がコミットされたＴｘＦログレコードを、コミットされていないものと区別す
ることが重要である。というのは、これによって、ＴｘＦログレコードが回復中
に適用されるか否かが決定されるからである。

【００７７】理解されるように、これが重要であるのは、やり直し中に動作を繰り返すこと
も、実際には行われなかった動作を元に戻すことも正しくないからである。例と
して、ＴｘＦログにログ記録される可能性がある下記の情況を検討されたい。

【００７８】

【表２】

【００７９】上の情況では、名前変更動作を逆転（元に戻す）ことが正しいかどうかを知る
ことができない。毎回逆転を単純に実行することは正しくない。というのは、名
前の変更が、ＮＴＦＳ内で実際に発生していない場合に、ＹがＸに名前を変更さ
れ、Ｘを置き換えるからである。その後、システムリンクをオープンしようとす
る試みの際に、ＮＴＦＳ動作が行われなかったのでリンクが存在しないので、そ
のオープンが失敗する。ファイルＸが失われ、ＹがＸに名前を変更された。しか
し、ＴｘＦ７０が、名前変更が行われたか否かを確認できる場合には、アンドゥ
動作を適用するか否かを正確に判定することができる。

【００８０】動作が実際に起こった、すなわち、ＮＴＦＳ６４によってコミットされたかど
うかを判定するために、動作を要求する前に、ＴｘＦが、対応するレコードをそ
のログ１２４に書き込む。その後、ＴｘＦは、ＴｘＦＬＳＮを受け取り、これ
を、所与のファイルについて要求された動作と共にＮＴＦＳ６６に供給する。Ｎ
ＴＦＳ６６に、コミットに続いて対応する（１つまたは複数の）ＮＴＦＳログレ
コードにＴｘＦＬＳＮを置かせることが可能ではあるが、これは非効率的であ
る。その代わりに、ＮＴＦＳが動作をコミットする時に、コミットの一部として
、ＮＴＦＳが、ＴｘＦＬＳＮを、そのファイルのＮＴＦＳボリューム上で維持
されるレコードに書き込む。ＮＴＦＳでは、マスタファイルテーブル１３０とし
て知られる構造体内で、ボリューム上の各ファイル（およびディレクトリ）に関
するレコードが、既に維持されている。したがって、ＴｘＦＬＳＮは、図１１
に一般的に示されているように、このファイル（たとえばファイル３）のレコー
ドのフィールド（たとえば１３２_３）に書き込まれる。その代わりに別のデータ
構造体を使用することができるが、ファイルごとのレコードが、各ＮＴＦＳボリ
ューム上で既に使用可能であることに留意されたい。

【００８１】その後、クラッシュに続いて、回復中に、ＴｘＦがＮＴＦＳにその回復を完全
に実行させた後に、ＴｘＦは、まず、ＴｘＦログにログ記録された動作がクラッ
シュの前にディスクに対して行われたか否かを判定するために検査する（Ｎｔｆ
ｓＴｘＦＧｅｔＴｘＦＬＳＮ（ｆｉｌｅ−ｉｄ、＊ＴｘＦＬｓｎ）呼出しを介し
てＮＴＦＳを呼び出すことによって）。ファイルに関するＮＴＦＳ動作が、クラ
ッシュの前にコミットされ、ディスクに存在した場合には、ＴｘＦログ１２４の
レコードのＴｘＦＬＳＮが、ファイルレコードフィールド内のＴｘＦＬＳＮ
以下である。というのは、ＮＴＦＳ回復によって、ファイルレコードが復元され
ることが保証されるからである。ファイルレコード内のＴｘＦＬＳＮが、Ｔｘ
Ｆログレコード内のＬＳＮ未満である（またはそのファイルのファイルレコード
内にない）場合には、ＮＴＦＳ動作がコミットされなかったこと、対応するＴｘ
Ｆログレコードを元に戻すために適用してはならないことがわかる。

【００８２】しかし、正しい回復を保証するために、回復ウィンドウ中にオブジェクトが削
除される場合に、ＴｘＦは、削除ログレコードがログ内で忘れられるまで、ファ
イルレコードの削除を遅延する（したがって、ｆｉｌｅ−ｉｄを保存する）。こ
れは、ファイルへのシステムリンクを作成することによって行われる。さらに、
新しいファイルが作成される場合に、ＴｘＦログレコードは、ＮＴＦＳが、作成
に使用しようとしているｆｉｌｅ−ｉｄを決定する後まで、書き込まれない。こ
れによって、ＴｘＦログ内にｆｉｌｅ−ｉｄが正確に記録される。非トランザク
ショナル作成についても、ＮＴＦＳは、ファイルレコード内に現在のＴｘＦＬ
ＳＮを書き込み、これによって、ｆｉｌｅ−ｉｄ（シーケンス番号を含む）が回
復ウィンドウ中に再利用される場合を処理し、ＴｘＦに、この作成の前のログレ
コードをスキップさせることが期待されることに留意されたい。

【００８３】次に、ＮｔｆｓＴｘＦＧｅｔＴｘＦＬＳＮ呼出しから、ｆｉｌｅ−ｉｄが回復
時に存在しないことがわかった場合には、トランザクションがコミットされた後
だがクラッシュの前に非トランザクショナルにファイルが削除されたか、作成動
作のすぐ後にクラッシュが起きたかのいずれかである。第１の場合に、ＴｘＦが
、かかわっておらず、ファイルレコードが、回復ウィンドウ中に削除されたこと
に留意されたい。第２の場合には、ＴｘＦ作成ログレコードが、ＴｘＦログディ
スクに送られたが、それに関するＮＴＦＳコミットが、持続しなかった。この第
２の場合は、作成ログレコードを処理する時に限って検出される。

【００８４】アンドゥレコードが、不完全なトランザクションの中断に使用されるので、ｆ
ｉｌｅ−ｉｄが存在しないことがＮｔｆｓＴｘＦＧｅｔＴｘＦＬＳＮによって見
られるレコードを、単純に無視することができる。

【００８５】中断中、クラッシュ回復中およびロールフォワード回復中に、ログによって駆
動されるやり直しアクションおよびアンドゥアクションが、ＮＴＦＳフィルタド
ライバモデルのフィルタドライバスタックの最上部で開始され、中間のフィルタ
ドライバがそのアクションを見ることができるようになることに留意されたい。
やり直しアクションおよびアンドゥアクションに対応するＩＲＰは、特別にマー
クされ、その結果、フィルタドライバが、それらを無視することを選択できるよ
うになる。これらのＩＲＰには、通常のトランザクション状態が含まれ、ファイ
ルオブジェクトは、普通にトランザクションオブジェクトをポイントする。しか
し、トランザクションが、特別な状態であるから、ＴｘＦは、それらを特別に扱
う必要があることを知る。たとえば、ＴｘＦは、これらのアクションをトランザ
クションに含めることを試みず、また、それらを非トランザクショナルとして扱
わない。

【００８６】名前空間動作をログ記録するほかに、ＴｘＦコンポーネント７０は、他の動作
の中でも、ページ変更を記録するためにログ記録サービス７４と共に働く。上で
述べたように、バージョンを保存し、中断の場合のアンドゥ動作もサポートする
ために、変更がＡＰＩを介してメモリ内のページに対して実際に行われる前に、
対応するアンドゥレコードが、ＴｘＦログ１２６に書き込まれる（強制されない
）。図１２に示されているように、その後、ページ全体が書き込まれ（通常は、
以下で説明するＴＯＰＳストリーム１３４と称する、ページのインメモリおよび
オンディスクのストリームに）、これによって、バージョン管理されるリーダー
が、単一のＩ／Ｏ動作でページを読み取ることが可能になる。ログ書込の後に、
このファイルの変更テーブル９８が、ログシーケンス番号（ＴｘＦＬＳＮおよ
びＴＯＰＳストリーム１３４内のオフセット）を用いてマークされ、その後、変
更がページに適用される。

【００８７】ページングＩ／Ｏを介して変更されたページ、たとえば、ユーザがマッピング
したセクションによって変更されたページおよび／または現在書き込まれつつあ
るＡＰＩの前の呼出しによって変更されたページから生じるものなどについて、
ページング書込が実行される。このページング書込は、バックグラウンドスレッ
ド内とすることができ、あるいは、コミット時のフラッシュの一部とすることが
できる。どの場合でも、ＴｘＦ７０は、まず、変更テーブル９８（図６）を検査
して、アンドゥがＴｘＦログ１２６に取り込まれているかどうかを調べる。そう
である場合には、システムは、テーブル９８内でマークされたＴｘＦＬＳＮま
でＴｘＦログ１２６を強制し、これは、ほとんどの場合に、Ｉ／Ｏなしでリター
ンする。変更テーブル９８がマークされていない場合には、ページのアンドゥバ
ージョンが、獲得され、ＴＯＰＳストリーム１３４およびＴｘＦログ１２６に書
き込まれる。複数ページＩ／Ｏが、一般的である。というのは、バックグラウン
ドスレッドが、ファイル−オフセットの順でページを一緒にグループ化すること
を試みるからである。これらの場合には、複数のアンドゥが、単一の大きいＩ／
Ｏで書き込まれる。そのような場合のアンドゥは、単一の大きいＩ／Ｏで読み取
られる。

【００８８】準備レコードをＴｘＦログ１２６に強制した後に、アンドゥイメージが、ディ
スク上でＴｘＦログ１２６およびＴＯＰＳストリーム１３４にあり、変更された
ファイルページが、ファイル内のそれぞれの位置にある。その結果、コミットが
、コミットレコードをログ１２６に書き込むという単純なことになる。中断は、
アンドゥレコードを逆の順序で進み、それをベースファイルに適用し、その後に
ファイルをフラッシュし、その後に中断レコードを強制的に書き込むことによっ
て達成される。これらのアンドゥレコードは、中断レコードがログ１２６に存在
する場合には回復時に無視される。頻繁でない動作（中断）中にファイルをフラ
ッシュすることによって、大きい（ページサイズの）補正ログレコード（ＣＬＲ
）をやり直しレコードとして書き込む必要がなくなり、スペースが大幅に節約さ
れることに留意されたい。

【００８９】アンドゥイメージの取得は、ページの前にコミットされたバージョンを得るの
と同一すなわち、ファイルのアンドゥイメージは、まず、ファイルの前のバージ
ョン内で検索される。イメージがメモリ内に常駐する場合には、アンドゥイメー
ジが、メモリから検索される。そうでない場合には、イメージは、キャッシング
されないＩ／Ｏ動作によってディスクから読み取られる。というのは、ダーティ
ビットが、プロセスプライベートであり、必ずしも既知ではないので、現在常駐
しているメモリイメージがダーティであるかどうかを判定する方法がないからで
ある。

【００９０】上で説明したように、書込用にファイルをオープンしたトランザクションによ
ってページが変更されるたびに、そのページが、その場ですなわちキャッシュ内
で編集される。キャッシュは、その後、さまざまな時にディスクに書き込まれる
（図８）。しかし、ページデータを変更する前に、古いページデータを保存する
必要があり、その結果、トランザクションが中断されるかシステムが障害を発生
した場合に、古いページデータを復元できるようにする。この目的のために、古
いページが、ＴＯＰＳストリーム１３４にコピーされ、その変更が、ＴｘＦログ
１２６にログ記録される。図１２に示されているように、ログレコード（たとえ
ばＸ_２）に、このページ内のオフセットが含まれ、これによって、ログ１２６が
データを維持する必要がなくなり、それに対応するレコードだけが維持される。
したがって、ページの復元をイネーブルするために、ＴｘＦは、経時的な変更を
シーケンシャルに記録する変更ログを使用する。バージョン管理のために、Ｔｘ
Ｆログ１２６にアクセスするのではなく、効率のために、変更テーブル９８内の
ＴＯＰＳストリーム１３４へのオフセットが使用されることに留意されたい。し
かし、システム障害の場合には、インメモリ構造体であるバージョンストリーム
制御ブロックが、回復時に存在しない。さらに、インメモリだけのファイルのす
べてのバージョンが、回復不能である。したがって、回復のために、ログ内のレ
コードを、障害中のトランザクションを中断し、障害の前にコミットされたトラ
ンザクションを耐久性のある形で完了するのに使用することができる。ログエン
トリ（またはログレコード）のシーケンシャルな性質によって、変更の順序が保
存される。

【００９１】本発明では、ページ書込に関するログレコードが、性能および他の理由から２
つの部分に分割される。メインログとインラインの部分では、他のログに関する
順序が保存され、他方の部分には、動作の詳細を提供する（かなり多数の）バイ
トすなわち変更されたページデータが含まれる。したがって、本発明の一態様に
よれば、図１２に示されているように、ページがトランザクションを介して変更
されるたびに、古いページデータが、（隣接する）ＴＯＰＳストリーム１３４に
コピーされ、変更がＴｘＦログ１２６にログ記録される。上で説明したように、
トランザクショナルリーダーをコピーされたページにマッピングするためにテー
ブルを調整した後に、そのページを変更することができる。図１２に示されてい
るように、ログレコード（たとえばＸ_２）に、コピーされたページのストリーム
内のこのページへのオフセットが含まれ、これによって、メインログでデータを
維持する必要がなくなり、それに対応するオフセットを有するレコードを維持す
るだけでよい。

【００９２】しかし、性能の理由から、これらのログは、異なる形でディスクにフラッシュ
される。その結果、ページもログ１２６も、所与の時点で持続していない場合が
あり、たとえば、ログ１２６がディスクにフラッシュされ、かつ／またはページ
がディスクにフラッシュされる前にシステムに障害が発生する場合がある。ペー
ジデータが失われないことを保証する単純な方法が、この２つの間の順序付けを
強制する、すなわち、ログレコードをディスクにフラッシュする前に必ずページ
をディスクにフラッシュすることである。その後、回復時にログを使用する時に
、ログレコードが存在する場合に、そのレコードに対応する正しいページバージ
ョンが、持続していることも既知になる。しかし、この順序依存性は、ログフラ
ッシュ動作が、多数の関連しない要因に依存して異なるログに対してより効率的
に動作するという点で、システム性能を大きく低下させることがわかった。たと
えば、性能を改善するために、ページは、通常は、遅延書込を使用して、たとえ
ば１時に１６ページなど、複数のセットでフラッシュされるが、ログは、満杯の
時またはバックグラウンドプロセスで異なる時にフラッシュされる可能性がある
。

【００９３】本発明のもう１つの態様によれば、ページおよびログを、互いに関して任意の
順序で、なおかつ障害の場合に正しいページが復元されることを保証する形で、
永続ストレージにフラッシュできるようにするシステムおよび方法が提供される
。これは、ログ１２６およびページデータに、事実上、この２つの情報を互いに
一貫性のある状態で、たとえば時間的にリンクする情報を追加することによって
達成される。具体的に言うと、ページの現在の状態を表すサイクルカウント１３
６（たとえば、１バイトだが、任意選択として１ワードまたはさらに長い単位を
使用することができる）が維持され、たとえば、サイクルカウントは、ＴＯＰＳ
ストリーム１３４へのポインタが先頭にラップアラウンドするたびに増分され、
そのサイクルカウントが、ログレコードと同期化される。

【００９４】本発明の一態様によれば、図１２に示されているように、ＴＯＰＳストリーム
１３４にコピーされたページに関連するログレコード内でサイクルカウント値を
維持することによって、同期化が達成される。これは、図１２では、一般的に、
レコードのデータフィールドの一部の展開された表現を提供する、符号１３８の
箱によって表される。やはり図示されているように、各セクタの最後の部分（た
とえばバイト）が、それを保存するためにログレコードにコピーされる。ページ
が、本明細書に記載のようにそれぞれ５１２バイトの８つのセクタを含むが、諒
解されるように、他のページサイズおよび／またはセクタサイズが可能であるこ
とに留意されたい。また、ストリームデータ内の各セクタの最後の部分は、図１
２で、各セクタの最後の部分で置換されたサイクルカウントを有するページデー
タの展開された表現を提供する符号１４０の箱によって一般的に示されるように
、サイクルカウントに置換される。図１２で表されているように、ページとログ
レコードの両方がフラッシュされる場合に、各セクタの末尾のサイクルカウント
値が、レコード内のサイクルカウント値と一致する、すなわち、両方が、一致す
る署名を有する。

【００９５】ページデータ（インラインでない部分）だけがディスクに書き込まれた場合に
は、システムは、インライン（ログ）レコードを見つけず、したがって、そのペ
ージは、見つからず、復元されるものはない。この状態は、一貫性があることが
わかっている。

【００９６】しかし、レコードがログに存在する場合には、ページは、システムクラッシュ
の前にフラッシュされた場合とそうでない場合がある。図１３は、一般的に、ロ
ールバック中にレコードに達した時に、ページおよびそのログレコードの両方が
ディスクにフラッシュされたかどうかを判定する論理を表す。まず、ステップ１
３００で、レコードにアクセスして、ストリーム１３４への保管されたオフセッ
トを介してページを見つける。次に、ステップ１３０２で、ページを読み取り、
それから抽出された各セクタの最後の部分を読み取り、ステップ１３０４で、ロ
グレコードに保管されたサイクルカウントと比較する。インライン（ログ）レコ
ードだけがディスクに書き込まれた場合には、クラッシュの後に、インラインで
ない部分（ページデータ）の各セクタに保管された一意の署名（各サイクルカウ
ント）が、インラインレコードデータに保管されたサイクルカウントと一致しな
い。この場合には、ステップ１３０６に示されているように、システムは、古い
ページがディスクに書き込まれなかったので、新しいページも書き込まれなかっ
た（これは、２つのログがフラッシュされる場合に限ってフラッシュされる）と
結論する。したがって、このページは、すでに、その前の、古い状態であること
がわかる。

【００９７】逆に、ステップ１３０４で、ログのサイクルカウントが、対応するページの各
セクタの最後の部分のサイクルカウントと一致する場合には、ログとページの両
方が、成功裡にフラッシュされたことがわかる。したがって、コピーされたペー
ジは、持続したことがわかり、これによって、ステップ１３０８で、ログレコー
ドに保管された各セクタの最後の部分が、コピーされたページに復元される。

【００９８】この時に、コピーされるページに、リーダーがアクセスすることができ、適当
なバージョンを提供することができる。現在のページに対して行われたログ記録
された変更のすべてを、新しいリーダーおよび／またはライタが見るのに使用す
ることができる（ステップ１３１０）。この場合に、古いデータが正しく取り込
まれ、中断の一部としてファイルページに復元されなければならないことがわか
る。中断にもかかわらず、既存のトランザクショナルリーダーが、ＴＯＰＳスト
リーム１３４から古いデータを読み取り続けることに留意されたい。

【００９９】各セクタの末尾の一意の署名の使用によって、さらに、ページのすべてではな
く一部がコピーされた、引き裂かれた（部分的な）書込が検出されることに留意
されたい。ディスクハードウェアは、セクタが完全に書き込まれることを保証す
るが、データのページ（たとえば８セクタ）が一単位として書き込まれることは
保証しないことに留意されたい。その場合には、サイクルカウントが、「ｎ」と
（おそらくは）「ｎ−１」の値の何らかの混合物になり、署名が、ログ記録され
た署名情報と一致しなくなる。そのような情況は、ページ全体が持続しなかった
かのように扱われる。

【０１００】サイクルカウント自体がラップアラウンドする時に、既存のページ（たとえば
比較的長い時間にわたってメモリ内にあったページ）の署名を構成するカウント
と一致し、したがって、部分的な書込が検出不能になる可能性があることに留意
されたい。たとえば、ラップしたサイクルカウントが使用され、かつ、それがペ
ージに保管された既存のサイクルカウントと一致する場合に、署名は、ページの
すべてまたはページの一部のどちらがコピーされる場合でも同一になる。理解さ
れるように、この場合の署名検査は、実際にはそうでない時にページデータ全体
が持続したことを示すはずである。

【０１０１】この問題は、複数の方法で解決することができる。そのような解決策の１つが
、各サイクルラップアラウンドイベントの後で一度ページを読み取って、一致が
ないことを検証することである。一致がある場合には、２つのサイクルカウント
の一方を調整して、一致を回避することができる。これがサイクルラップアラウ
ンドごとに１回だけ（すなわち、サイクルカウントが０にラップするたびに）発
生することを保証するために、別の検証ビットマップ１４１を使用して、各ペー
ジの「検証」状態を維持することができる。すなわち、各ビットが、ラップの後
にある状態になり、サイクルカウント一致についてページが初めて検査される時
にトグルされる。フリースペースビットマップを使用して、ページが空いている
か使用中かを追跡し、効率のために、上の解決策で、追加のビットマップを追加
して検証状態を追跡することに留意されたい。

【０１０２】代替の解決策（上で説明した読取および比較動作に対する）は、やはり検証状
態を追跡することであるが、「検証」状態がページ使用の時にセットされる時に
、サイクルカウントを、上で説明したようにページに書き込み、書込を強制する
ことである。書込に成功する場合には、その書込は部分的でない。大きいＴＯＰ
Ｓストリームの場合に、この代替案は、サイクルカウントがページと一致するこ
とが比較的まれである可能性が高いので、少数の入出力Ｉ／Ｏ動作に起因してよ
くスケーリングされる。

【０１０３】もう１つの代替案は、最初の２つの解決策を、ページ冗長性の検査と組み合わ
せることである。すなわち、ページが高速メモリに常駐する場合に、実際のディ
スク読取が不要なので第１（読取）代替案を実行し、そうでない場合に第２（書
込）代替案を実行する。

【０１０４】遅延やり直しの代替案上で説明した回復機構は、ファイルのダーティページをコミット時にディスク
に書き込み、これによって、トランザクションにまたがるページ書込のバッチ化
が妨げられる。トランザクションにまたがるページ書込のバッチ化を達成するた
めに、回復に関してその逆を実行する、代替の「遅延やり直し」方式を提供する
ことができる。この方式では、やり直しレコードをログに書き込み、ベースファ
イルを読み取っているリーダーがない時に、古いコミットされたトランザクショ
ンをベースファイルに適用する。古いコミットされたバージョンの読取をサポー
トするために、変更を、インプレース（その場）で行うのではなく、ページの既
存のインプレースバージョンがもはや不要である時に限ってインプレースでファ
イルに適用することができる。

【０１０５】遅延やり直し方式は、インプレース更新方式によって使用される原理の多数を
共有し、たとえば、非常に似た形のバージョン管理を、バージョン制御ブロック
および複数のインメモリストリームを用いてサポートする。しかし、変更テーブ
ルは、アンドゥではなく、やり直しページのＬＳＮを保持する。図１４に一般的
に示されているように、最も古いディスクバージョンが、必ずベースファイルに
なり、より新しいバージョンは、その上での増分変更を構築する。より古いバー
ジョンは、リーダーがいなくなる時に、ベースファイルにマージされる。この方
式の主な長所を活用するために、複数のバージョンを、同一時にベースファイル
にマージすることができ、したがって、Ｉ／Ｏ効率が得られる。複数のバージョ
ンを同一時にマージすることのもう１つの利益は、ログを長い読取で効率的に読
み取ることができることである。

【０１０６】しかし、ログに、（おそらくは多数の）アクティブファイルについてメモリを
バッキングするページが書き込まれる可能性があり、本質的に、シーケンシャル
ログが、回復ログの二役にもなるランダムページファイルになり、これがシステ
ムのボトルネックになる可能性がある。

【０１０７】インプレース更新方式に似て、最新バージョンは、更新可能である。すべての
バージョンに関連するバージョン制御ブロック（ＴｘＦＶＳＣＢ）があり、各Ｔ
ｘＦＶＳＣＢは、バージョンによって変更されたページ番号を記録するインメモ
リテーブルである変更テーブルをポイントする。各ページ番号と共に、少なくと
も１回書き込まれている（やり直しイメージ）場合に、ディスク上のページを見
つけるためにディスクアドレスを保管することができる。ディスクアドレスがな
いことは、ページが一度もディスクに書き込まれていないことを意味する。メモ
リを節約するために、ページがディスクに連続的に保管されている場合に、ペー
ジ範囲を１エントリに保管することができる。

【０１０８】バージョンＬＳＮは、そのバージョンをコミットしたトランザクションのコミ
ットレコードのＬＳＮである。現在更新可能なバージョンについては、そのよう
なＬＳＮはない。ＳＯＰポインタは、このバージョンに対応するセクションオブ
ジェクトポインタ構造体へのポインタである。このポインタを使用して、インメ
モリページを見つけることができる。バージョン長も、同様に提供される。

【０１０９】バージョン制御ブロックは、リスト内で時間順にリンクされる。最も古いバー
ジョンが、ベースストリームであり、変更テーブルには、このバージョンのエン
トリが一切含まれない。

【０１１０】オープンの時に、バージョンの１つが、上で説明した代替方式と同様に、ファ
イルハンドルに与えられる。最新バージョンのインメモリストリームは、ログに
よって部分的にバッキングされる（完全にベースファイルによるのではない）。
したがって、ストリームに対する変更は、ログに書き込まれる。読取は、ページ
がバージョンウィンドウ内のどのバージョンでも変更されていない場合にはベー
スファイルから行われ、そうでない場合には、ログから行われる。

【０１１１】読取の時に、そのバージョンに対応する変更テーブルに問い合わせて、ページ
がそのバージョンで変更されているかどうかを判定する。そうである場合には、
Ｉ／Ｏを、ログ内の適当な場所に向けて、ページを取り込んで、フォールトを満
足する。そうでない場合には、ページについて、次に前のバージョンに問い合わ
せる。この処理は、ページの最も最近にコミットされたコピーが見つかるまで継
続される。複数のバージョンに、ページのコピーが含まれる場合には、ＶＭＭ呼
出しによってそれらのメモリ常駐性（ｒｅｓｉｄｅｎｃｙ）を検査する。メモリ
常駐ページが見つかった場合には、それをコピーし、そうでない場合には、最も
最近のバージョンのＬＳＮを使用してログから読み取る。ページが、常駐性が検
査された時とコピーが行われた時の間にシステムメモリからトリミングされたか
どうかが重要でないことに留意されたい。というのは、再帰的なフォールトが生
成され、その後にページがコピーされるからである。これらのページをコピーす
る先のシステムアドレスを得るために、キャッシュマネージャを使用して、それ
らをシステムアドレス空間にマッピングする。

【０１１２】図１４では、４つのバージョンＶ０〜Ｖ３が示されており、（他の個数が実現
可能であるが）、「Ｘ」を用いてマークされたページが、バージョン内の変更を
表す。変更テーブル１４２_０〜１４２_３に、書き込まれたページのＬＳＮが示さ
れている。最も最近の（更新可能な）バージョンの一部のページは、まだ書き込
まれていない。このシナリオでは、ＦｉｌｅＯｂｊｅｃｔ_Ｂがページ５０にアク
セスする例を検討されたい。ファイルバージョンＶ１の変更テーブル１４２_１に
、このページがそのバージョンで変更されていないことが示されている。したが
って、フォールトは、そのページのファイルバージョンＶ０の常駐性を検査し、
常駐する場合に（フォールトをとりあげないで）それをコピーすることによって
処理される。ファイルバージョンＶ０が、ページ常駐を有しない場合には、ディ
スクから読み取る（この場合には、ベースファイルから）。

【０１１３】もう１つの例として、ＦｉｌｅＯｂｊｅｃｔ_Ｂが、ページ２００にアクセスし
、そのページが、メモリ内にある場合に、アクセスは単純に機能する。しかし、
そうでない場合には、ページフォールトが生成され、読取は、ログのＬＳＮ２５
００から読み取ることによって満足される。

【０１１４】もう１つの例として、ページ１００にアクセスするＦｉｌｅＯｂｊｅｃｔ_Ｃを
検討されたい。このページは、バージョンＶ２で変更されていないので、バー
ジョンＶ１が検査され、読取は、メモリイメージ（常駐する場合）から、または
ログのＬＳＮ２０００を読み取ることのいずれかによって満足される。

【０１１５】ファイル書込について、ページアウトの時に、ページが、ストリームオフセッ
トおよびストリーム名も記述するやり直しレコードの形でログに書き込まれる。
この時に、ＬＳＮが、そのバージョンの変更テーブルのページスロット内でマー
クされる。ページ書込は、システムスレッドの１つによってバックグラウンドで
行われ、通常は、シーケンシャルページ順で書き込まれる。コミットの時に、そ
のバージョン内のダーティページが、ログに書き込まれ、それにコミットレコー
ドが続く。ページが、トランザクション中に複数回書き出される場合には、複数
のログ書込が行われる。これらの書込は、ログの末尾に行き、変更テーブルエン
トリが、新しい位置をポイントするように変更される。間に入る読取トランザク
ションなしでコミットの後に新しい書込トランザクションがスタートする場合に
は、メインメモリストリームが、新しいトランザクションによって再利用される
。そうでない場合には、メインメモリストリームが、リーダーによって請求され
、ライタトランザクションは、新しいストリームを作成し、これを処理する。遅
延やり直し方式では、変更されたページが、ＴＯＰＳストリームに書き込まれて
（まさにインプレース更新方式と同様に）、関連する利益が達成されることに留
意されたい。

【０１１６】クラッシュの後に、回復は、比較的簡単である。というのは、コミットされた
トランザクションのやり直し情報が、ログにあり、メインデータストリームに簡
単に適用できるからである。バージョン制御ブロックが、インメモリ構造体であ
り、したがって、回復時に存在しないことに留意されたい。

【０１１７】古いリーダーがトランザクションを終了する時に、古いバージョンは、もはや
保存する必要がない。そのような時に、バージョンが、最も古いものから始めて
、１時に１バージョンずつメインストリームにマージされる。バージョンは、マ
ージされる時に、バージョンのリンクリストから除去される。マージは、そのバ
ージョンの変更されたページ（ページ番号は変更テーブル内でルックアップされ
る）をベースストリームにコピーし、ディスクに強制することによって、１時に
１ページずつ行われる。このコピー動作では、現在常駐していないページについ
て、ログを読み取る。可能な場合には、ログからページ範囲を取り込むために、
大量のＩ／Ｏが行われる。たとえば、図１４では、バージョン管理をサポートす
るためにバージョンＶ０がこれ以上必要でない場合に、バージョンＶ１をバージ
ョンＶ０にマージすることができる。このマージは、バージョンＶ１をロックせ
ずに行うことができる。というのは、マージが進行中である間は、各ページのコ
ピーが、バージョンＶ１およびバージョンＶ０に存在し、バージョンＶ１の変更
テーブルが、この処理を介して変更されないからである。

【０１１８】マージが完了した後に、バージョンＶ１がバージョンウィンドウ内にない場合
には、Ｖ１のバージョン制御ブロックを、単純にバージョンのリストから除去す
る。一般に、マージは、複数のバージョンがリーダーから解放されるまで遅延さ
れる。この例では、Ｖ０、Ｖ１、およびＶ２を、これらがバージョンウィンドウ
から出た時に、一緒にベースファイルにマージすることができる。複数バージョ
ンマージについて、変更テーブルが、まず、同一エントリが複数のテーブル内で
変更される時に、最高のバージョン番号からのＬＳＮが選択される形でマージさ
れる。これは、本質的に、トランザクションにまたがる書込をバッチ化し、この
方式の長所の１つである。バージョンをマージした後に、そのログレコードは、
アクティブログからの除去の資格がある。

【０１１９】一般に、マージは、できる限り早く行われる。リーダーがいなくなるたびに、
バージョンウィンドウが前方に移動する。その時に、いくつかのバージョンを、
マージの資格があるものとしてマークすることができる。複数のバージョンがマ
ークされた時に、作業アイテムが、マージを行うためにシステムスレッドの１つ
に置かれる。

【０１２０】インプレース更新方式と遅延やり直し方式の両方が、ほぼ同一の数のＩ／Ｏを
実行する。インプレース更新方式は、アンドゥを同期式に読み取る（並列リーダ
ーが最近読み取った場合など、アンドゥが時々メモリ内で見つかる場合があるの
で）。インプレース更新方式は、ページをベースファイルに書き出し、アンドゥ
をログにシーケンシャルに書き込む。対照的に、遅延やり直し方式は、やり直し
を多数のランダムＩ／Ｏで書き込む必要があり、ログをランダムに読み取ってバ
ージョンをマージする必要がある。さらに、遅延やり直し方式は、バージョンに
またがる書き込みを最小にするが、ファイルページをディスクに書き込む必要が
ある。これらのログページがメモリ内で見つかる可能性は、したがって、マージ
が遅延される長さに関して、非常に低い。

【０１２１】いつどこでＩ／Ｏが行われるかに、定性的な差がある。遅延やり直し方式では
、最も最近のメモリストリームが、ベースファイルではなく、ログによってバッ
キングされる。これは、最も一般的に使用されるストリームになる可能性が非常
に高い。というのは、これが、更新された作業を処理し、比較的にログに重荷を
課すからである。バージョン管理されるリーダーについて、両方の方式が、ログ
をページングデバイスとして使用する。

【０１２２】遅延やり直し方式は、大量のトランザクション作業がバックグラウンドで実行
されるので、コミット処理と同期して行う作業がより少ないが、書込ＡＰＩまた
はメモリ更新がキャッシュに対して実行されるので、書込ＡＰＩまたはメモリ更
新のそれぞれについて、ライタにとってより高速には見えない。その代わりに、
コミット時のフラッシュに、コミットの応答性の差が現れる。より大きい更新ト
ランザクションについて、バックグラウンドシステムスレッドが、非同期書込を
スケジューリングする可能性が高く、これによって、多少は応答性の差が減る。
同様に、インプレース更新方式は、ファイルＡＰＩに関するアンドゥ作業をバッ
クグラウンドで行うことによって、多少はコミット時の重荷を減らすことができ
るが、ユーザがマッピングしたセクションで行われた変更について実現可能では
ない。

【０１２３】インプレース更新方式は、遅延やり直し方式より複雑でない。というのは、イ
ンプレース更新方式が、非同期マージ動作のスケジューリングの問題を扱う必要
がないからである。また、インプレース更新方式は、フォアグラウンドアクティ
ビティとバックグラウンドアクティビティの間の速度不一致の問題を扱う必要が
ない。この速度不一致は、時々、ログスペースをブロックし、リソース獲得問題
を生じる。

【０１２４】最後に、アーカイブ作成およびロールフォワードは、遅延やり直し方式を用い
る場合に、やり直しレコードがログ内で使用可能なので、通常のランタイムログ
記録アルゴリズムを変更せずに可能である。しかし、アンドゥレコードがないの
で、トランザクションに関してやり直しを適用する前に、トランザクションのコ
ミット状況を見つけるために、ログの多少の前方スキャンを行う必要がある。

【０１２５】ネットワークを介するファイルシステムトランザクションリモートファイルは、図１５に一般的に示されているように、内部カーネル対
カーネル「リダイレクタ」プロトコル（たとえば、ＳＭＢプロトコル）を介して
アクセスされる。このプロトコルは、クライアントコンピュータ１４６で実行さ
れるファイルシステム動作を、リモートコンピュータ１４８、たとえばサーバ上
で反映する。もちろん、他のプロトコルおよび機構（たとえば、ＷｅｖＤＡＶ
、ＮＦＳなど）によって、同等の結果を達成することができる。この目的のため
に、非トランザクショナルファイルシステムアクセスと同様に、リモートファイ
ルが、識別され、ＩＲＰが、クライアントコンピュータ１４６上のリダイレクタ
ファイルシステムドライバ１５０に向けられる。既知のように、このドライバ１
５０は、クライアントコンピュータのキャッシュと対話して、データを読み取り
、書き込む。リモートコンピュータのファイルシステム１５４に向けられたアプ
リケーション１５２からのファイルシステム要求などの要求（たとえば、リモー
トディスク１５６上のファイルＧ：＼Ｆｎａｍｅへのアクセス）は、リダイレク
タドライバ１５０によってインターセプトされ、リモートコンピュータ１４８に
送信され、ここで、エージェント１５８（デーモン）スレッドが、それらをドラ
イバスタックの最上のファイルシステム動作に変換する。

【０１２６】リモートトランザクショナルファイルシステム動作に関して、ファイルをオー
プンするために、クライアントリダイレクタが、たとえば、ＣＯＭ／ＯＬＥを使
用して、ＤＴＣトランザクションオブジェクト１６０_Ｃを、サーバ１４８にオー
プン要求と共に供給されるフラットバイトストリームにマーシャリングする。諒
解できるように、他の機構が、同等の機能および／または結果を達成することが
でき、ＣＯＭ／ＯＬＥ動作を本明細書で説明するが、本発明のこの態様は、ＣＯ
Ｍ／ＯＬＥに制限されない。ＣＯＭ／ＯＬＥの例では、トランザクションオブジ
ェクト１６０_Ｃが、オープンを要求するクライアントスレッドにアタッチされる
。サーバコンピュータ１４８は、そのカーネル空間内にＤＴＣトランザクション
オブジェクト１６０_Ｓのコピーを保持できる限り、トランザクションがどこから
発するかに関係しないことに留意されたい。同様に、サーバ１４８は、トランザ
クションの代わりにどのスレッドまたはプロセスが働くかに関心を持たない。そ
うではなく、サーバ１４８のエージェント１５８が、フラットバイトストリーム
を使用可能なオブジェクトに変換し、このオブジェクトが、カーネル内で使用可
能になる。この時に、サーバは、要求をローカルトランザクション１６０_Ｓと同
様に扱い、それをサーバ上の対応するＤＴＣプロキシ１６２_Ｓに参加させ、本質
的に、ＤＴＣに、後続のトランザクション作業についてサーバ１４８（および、
リソースマネージャとしてその中のＴｘＦコンポーネント１６４）に連絡するよ
うに指示する。サーバが、このトランザクションオブジェクト１６０_Ｓを所有す
るので、これが適当であることに留意されたい。トランザクションＩＤは、分散
名前空間にあるので、トランザクションは、どこからでも発することができるが
、トランザクションｉｄに基づく正しいファイル同期化は、サーバ１４８で行わ
れる。

【０１２７】サーバは、本質的に、ファイルシステム要求を、ローカルの場合に関するもの
であるかのように扱い、これによって、ローカルＴｘＦコンポーネント１６４が
、トランザクショナルファイルシステム要求を処理する。しかし、サーバ１４８
は、対応するファイルオブジェクトが、クライアント１４６によってオープンさ
れたファイルに関するものであることを記憶し、クライアントがページをキャッ
シングしたことを記憶する。したがって、コミット時に、サーバ１４８は、クラ
イアント１４６に（リダイレクタプロトコルを介して）そのキャッシュをサーバ
にフラッシュし、クライアント側でオープンされた可能性があるマッピングされ
たセクションのすべてをフラッシュする（クライアントが、マッピングされたセ
クションについて追跡する）ように通知する。データは、普通に、多少遅れた形
で、すなわち、クライアントのキャッシュ／メモリからページアウトされる時に
必ず、サーバ１４８に到達する。データが到達する時に、そのデータによって、
サーバのキャッシングされたコピーが上書きされる。これが、複数のオープンハ
ンドルまたはマッピングされたセクションがお互いを上書きする、従来のファイ
ルシステムモデルに類似することに留意されたい。

【０１２８】リダイレクタベースのファイル作成動作に関して、ユーザモードのＣｒｅａｔ
ｅＦｉｌｅＥｘがＩＴｒａｎｓａｃｔｉｏｎオブジェクトを（たとえばＤＴＣの
ＩｔｒａｎｓａｃｔｉｏｎＴｒａｎｓｍｉｔｔｅｒメソッドを介して）バイトの
フラットコレクションにマーシャリングするという、上で説明した概念が、ネッ
トワークを介するＩＴｒａｎｓａｃｔｉｏｎのマーシャリングにも使用される。
ＩＴｒａｎｓａｃｔｉｏｎＴｒａｎｓｍｉｔｔｅｒ呼出しではトランザクション
マネージャとの通信が不要なので、これは比較的安価であり、したがって、作成
ごとに行うことができる。しかし、Ｒｅｃｅｉｖｅ呼出し（上で説明した）は、
トランザクションコーディネータ（またはそのプロキシ）との通信を必要とし、
このトランザクションコーディネータは、リダイレクタベースの場合に、リモー
トコンピュータ１４８上にある。それにもかかわらず、ＩＴｒａｎｓａｃｔｉｏ
ｎＲｅｃｅｉｖｅｒが、ネットワーク全体で（サーバ１４８上で）トランザクシ
ョンごとに１回だけ行われるので、このトランザクションコーディネータ１６２_Ｓとの通信のコストは、大きくない。

【０１２９】したがって、このようにして、トランザクショナルリモートファイルアクセス
が、透過的にサポートされる。すなわち、アプリケーションが、本質的に、リモ
ートファイルアクセスを使用して、ならびに複数のコンピュータでアプリケーシ
ョンプロキシを作成することによって直接に、ネットワーク上のどこにあるファ
イルでもアクセスすることができる。その結果として、同一のトランザクション
に、１つまたは複数のローカルプロセスとリモートプロセスを同時に含めること
ができる。

【０１３０】リダイレクタプロトコルは、一般的に、単一のクライアントがファイルをリモ
ートアクセス用にオープンさせた場合について最適化される。その場合に、ファ
イルのローカルディスクキャッシュを保持することによって、多数のネットワー
クトラフィックが、回避される。変更は、必要な時だけすなわち、ファイルのク
ローズの時だけフラッシュされる。しかし、この配置は、別のクライアントが同
一のファイルを同時にオープンした時に、必ずディスエーブルされる。便宜的ロ
ック（ｏｐｐｏｒｔｕｎｉｓｔｉｃｌｏｃｋ）（Ｏｐｌｏｃｋ、本質的に所有
権を示すトークン）によってこれがイネーブルされ、これによって、上の「クロ
ーズ時にフラッシュ」方式に対する変更が最小になる。具体的に言うと、コミッ
ト時に、クライアントが、通常のように、サーバに変更をフラッシュするように
求められる。中断の時には、クライアントが、クライアントハンドルを「運が尽
きた」としてマークするように求められ、ハンドルがクローズされた後に、変更
が単純に捨てられるようになる。リダイレクタプロトコルを強化して、サーバが
、ローカルの場合と同様に、いくつかの情況でクライアントがマッピングしたセ
クションを無効化できるようにすることができることに留意されたい。

【０１３１】名前空間分離トランザクションの変更を他のトランザクションから分離することが、トラン
ザクションの重要なプロパティである。トランザクショナルファイルシステムで
は、分離が、ファイルに保管されるデータ（上で説明した）だけではなく、ファ
イルおよびファイルがその下で編成されるディレクトリの名前階層にも適用され
る。本発明のもう１つの態様によれば、ファイル／ディレクトリ名前階層内で名
前空間分離を実施する技法が提供される。この技法は、トランザクションの期間
にわたる名前またはディレクトリのロックを必要とせず、トランザクションに使
用されているファイルに対して試みられる非トランザクショナル動作と共に動作
する。

【０１３２】たとえば、まだコミットしていないトランザクションによって作成されたファ
イルを検討されたい。ファイルの代わりに、ディレクトリを作成することができ
るが、説明を単純にするために、本発明を、主にファイルに関して説明すること
に留意されたい。しかし、ファイルおよびディレクトリが、以下で説明する名前
空間動作に関して一般的に同等に扱われることを理解されたい。トランザクショ
ンによって作成されたファイル（またはディレクトリ）は、それを作成するトラ
ンザクションからは制約なしでアクセス可能でなければならないが、他のトラン
ザクション、たとえばそれをオープンしようとする別のトランザクションまたは
その親ディレクトリをリストしようとする別のトランザクションに可視になって
はならない。作成するトランザクションがコミットする時に限って、そのファイ
ルを他のトランザクションに可視にしなければならず、そのかわりに中断された
場合には、ファイルが他のトランザクションに可視になってはならない。非トラ
ンザクション（たとえば、親ディレクトリの列挙を要求するもの）は、そのよう
なファイルを見るが、しかし、そのようなファイルを、コミットされるまで非ト
ランザクションに不可視にすることが、代替的に可能である。

【０１３３】同様に、ファイル（またはディレクトリ）が、まだコミットしていないトラン
ザクションによって削除される場合に、削除されるファイルは、コミットの時ま
で、削除が全く発生しなかったかのように、他のトランザクションからアクセス
可能であり続ける必要がある。しかし、削除するトランザクションは、削除の影
響を見、その場所で同一の名前を持つ異なるファイルを作成することができる。
コミット時に、削除されたファイルが、除去される。非トランザクションは、削
除の影響を見る。すなわち、削除されたファイルを見ないが、非トランザクショ
ンは、そのファイル／ディレクトリを削除したトランザクションが中断し、削除
が元に戻される場合の衝突を避けるために、コミットしていないトランザクショ
ンによって削除されたものと同一の名前の新しいファイルを作成することができ
ない。やはり、その代わりに、非トランザクションを、異なるトランザクション
であるかのように扱い、したがって、トランザクションによって削除されたファ
イルを見続けるようにすることが、実現可能ではあるが、これは好ましくない。

【０１３４】さらに、ファイル（またはディレクトリ）が、トランザクションによって名前
を変更される場合に、そのファイルは、他のトランザクションに関して元のディ
レクトリ内で元の名前で使用可能であり続け、新しい名前は、他のトランザクシ
ョンに可視にならない。名前を変更するトランザクションは、名前変更の影響を
見、古い名前を使用して異なるファイルを作成することができる。名前変更が、
本質的に、新しいリンクの作成と古いリンクの削除の組合せであることに留意さ
れたい。

【０１３５】上で説明したシナリオを処理するために名前空間分離を達成するために、本発
明は、トランザクションの期間について、他のトランザクションによる使用のた
めに名前空間の状態を保存する。この目的のために、図１６〜１８に示されてい
るように、分離ディレクトリ１７０_１〜１７０_４と称する別のディレクトリが、
作成され、名前空間動作を実行するトランザクションによって変更される各々の
ＮＴＦＳディレクトリにリンクされる。具体的に言うと、各分離ディレクトリ（
たとえば１７０_１）には、親ディレクトリ（たとえばディレクトリＤ３）のＴｘ
ＦＳＣＢ構造体に関連する検索構造体（たとえば、２進検索木）が含まれる。さ
らに、分離ディレクトリ検索構造体および関連する操作ルーチンに、エントリの
追加、名前を用いるエントリの高速ルックアップをサポートし、ディレクトリ列
挙アルゴリズムもサポートする一般インターフェースが含まれる。

【０１３６】これらの分離ディレクトリには、名前空間変更を行ったトランザクションによ
って影響される個々の名前が含まれ、これらの分離ディレクトリは、メインメモ
リ構造体だけである。この構造体の各エントリには、名前に関連するトランザク
ションＩＤ（Ｔｉｄ）と、トランザクションＴｉｄに可視と他者に可視の２つの
フラグを有する可視性ディスポジション（ｖｉｓｉｂｉｌｉｔｙｄｉｓｐｏｓ
ｉｔｉｏｎ）も含まれる。これらの可視性フラグの一方または両方を、独立にセ
ットすることができる。分離ディレクトリ構造には、ＳｈｏｒｔＮａｍｅ／Ｌｏ
ｎｇＮａｍｅフラグも含まれ、ここで、ペアリングが使用可能である場合に、構
造体に、ペアリングされた名前に対応する構造体へのポインタが含まれる。名前
がＴｉｄによって予約され、他者がそれを請求できないことを示すフラグ、Ｆｉ
ｄ（削除された名前および変更された名前に関してｃｒｅａｔｅ（）をリダイレ
クトするのに使用される）、および他の情報すなわち、ディレクトリ列挙に使用
される、タイムスタンプおよび類似物などのＮＴＦＳによって複製される情報も
提供される。スペース効率のために、構造体を、Ｎａｍｅ、情報へのポインタ、
他の名前へのポインタ、および他の情報に分離することができる。これによって
、２つの名前によって共有される他の情報の単一の組がもたらされる。

【０１３７】分離ディレクトリが使用される方法の例として、図１６に示されているように
、ファイルＦ３が、トランザクションＴ１によって削除される場合に、ファイル
Ｆ３の名前およびさまざまな情報が、その名前がＮＴＦＳディレクトリＤ３から
除去されるのと（本質的に）同時に、分離ディレクトリ１７０_１に追加される。
ＮＴＦＳでファイルを削除するためには、オープンファイルが削除についてマー
クされ、ファイルシステムが、オープンハンドルのカウントを維持しながらその
ファイルをクローズし、オープンされたままのハンドルがなくなった時に削除を
実行することに留意されたい。さらに、分離ディレクトリ１７０_１は、このトラ
ンザクションＴ１または別のトランザクション（たとえばＴ２）による以前の動
作から既に存在する可能性があり、あるいは、この削除動作をサポートするのに
必要な場合に作成される可能性があることに留意されたい。削除動作を、さらに
、以下で図１９の流れ図に関して説明する。

【０１３８】このファイルＦ３への、異なるトランザクション（たとえばＴ２）による後続
のアクセスは、分離ディレクトリ１７０_１を使用してサービスされ、これによっ
て、トランザクションＴ２が、ファイルＦ３を見続ける。しかし、ファイルＦ３
を削除したのと同一のトランザクションＴ１（または非トランザクション）が、
ファイルＦ３を探す場合には、このファイルが見つからない。この情況を処理す
るために、上で説明したように、ファイルの名前、その可視性ディスポジション
、ファイルを削除したトランザクションのＩＤ、リダイレクトファイルＩＤ、＄
ＴｘＦファイル識別子（たとえば、単調増加するシーケンス番号）、および複製
情報（日付スタンプ、サイズ、属性）が、ファイルについて維持される。

【０１３９】図１９に、オープンされているファイルの削除の要求を処理する一般的な論理
の表現を示す。図１９および類似する流れ図が、分離ディレクトリが使用される
方法の理解を提供するために単純化されており、基礎となるコードの正確な表現
とみなされてはならず、たとえば、特殊な場合、エラー処理などが含まれないこ
とに留意されたい。どの場合でも、ステップ１９００で開始されて、被トランザ
クション要求元エンティティと非被トランザクション要求元エンティティの間の
区別を行う。というのは、被トランザクションユーザが、非被トランザクション
ユーザの削除動作と異なる動作をもたらすからである。非トランザクションがフ
ァイルの削除を要求している（そのハンドルによって識別される）場合には、削
除が、それ以外は通常の形で実行される。すなわち、ステップ１９０２で、指定
されたファイルがディスクから削除される。削除は、最後のハンドルがクローズ
された時に始まる。

【０１４０】ステップ１９００で、トランザクション（たとえばＴｉｄ１）が削除を要求し
ている場合に、ステップ１９０４が実行され、ここで、本質的にファイルの名前
が変更される。たとえば、図１６に一般的に示されているように、任意の名前（
たとえば「０」）が、隠されたディレクトリ１６８（＄ＴｘＦ）に追加され、こ
の名前が、マスタファイルテーブル１３０（図１１）のファイルのレコードにリ
ンクされる。それと同時に、削除されたファイルＦ３からのリンクが、親ディレ
クトリＤ３から除去される。

【０１４１】その後、削除情報すなわち、ファイル名Ｆ３、元の親に関する参照、および新
しいリンク情報が、ステップ１９０６で削除レコードにログ記録される。ファイ
ルを削除しつつあるトランザクションがコミットする前にシステムがクラッシュ
する場合には、トランザクションが中断され、ログから、上で説明したようにフ
ァイルの名前を単純に変更することによって、すなわち、前のリンクを復元する
ことによって（＄ＴｘＦディレクトリは、インメモリ構造体なのでなくなる）フ
ァイルが正しく復元される。

【０１４２】本発明によれば、ファイル情報が、通常のディレクトリＤ３にリンクされた分
離ディレクトリ１７０_１に追加される。分離ディレクトリ１７０_１は、通常のデ
ィレクトリに関連して既に存在する場合があるが、そうでない場合には作成され
る。ステップ１９１０を実行して、トランザクションＴｉｄ１がこのファイルの
削除を要求したことを示すように可視性ディスポジションフラグを適用に調整し
、その結果、このファイルが、他のトランザクションにはまだ可視であるが、Ｔ
ｉｄ１には不可視になるようにする。ステップ１９１２で、任意の名前を付けら
れたリンクを、後に（すなわちトランザクションがコミットした後に）ディスク
から削除されるファイルのリストに追加する。

【０１４３】トランザクションに対応する名前エントリは、そのトランザクションが終了す
る時に分離ディレクトリから除去され、分離ディレクトリは、そこに残っている
エントリがなくなった時に、削除することができる。システムがクラッシュする
場合に、インメモリ構造体である分離ディレクトリが、失われることに留意され
たい。しかし、クラッシュによって、コミットされていないトランザクションが
中断されるので、分離ディレクトリは、もはや分離のために必要ではなくなり、
ログファイルのアンローリングによって、ファイルの状態が適当にリセットされ
る。

【０１４４】ファイルの作成は、ファイルがトランザクション（たとえばＴｉｄ２）によっ
てディレクトリ内で作成される時に、名前が、（親）ＮＴＦＳディレクトリにリ
ンクされた分離ディレクトリに実際に追加されるという点で、削除に多少似てい
る。他のトランザクションに関して、名前は、トランザクションがコミットする
まで、ファイルをオープンする目的に関するまたは親ＮＴＦＳディレクトリをリ
ストする時の可視性フラグの設定によってフィルタアウトされる。Ｔｉｄ２およ
び非トランザクションに関して、作成されたファイルは、コミットされる前に可
視である。

【０１４５】名前を付けられたエントリは、追加された後に、トランザクションによって変
更することができる。たとえば、ファイルが削除され、同一の名前を使用して別
のファイルが作成される場合に、作成によって、エントリの状態が変更され、他
のトランザクションが、削除の前に存在したファイルを見続けるが、このトラン
ザクションが、作成されたばかりの新しいファイルを見るようになる。ＮＴＦＳ
ディレクトリまたは分離ディレクトリに対して、トランザクションレベルのロッ
クが保持されないことに留意されたい。これによって、システムが、ベースファ
イルシステムより並列性が低くならないようにすることができる。

【０１４６】図１８に示されているように、ファイルＦ６が、トランザクションＴｉｄ２に
よって作成される（作成は、普通の親ディレクトリＤ４内で要求される）場合に
、Ｆ６が、ディレクトリＤ４内に作成され、それのためのエントリが、親ディレ
クトリＤ４に関連する分離ディレクトリ１７０_２に追加される。分離ディレクト
リ１７０_２は、必要であれば作成される。フラグが、Ｔｉｄ２の作成状況を反映
するように適当に調整される。すなわち、Ｔｉｄ２に可視であるが、他のトラン
ザクションには不可視になり、名前がＴｉｄ２用に予約される。トランザクショ
ンＴｉｄ２が、Ｔｉｄ２がコミットする前に、新たに作成されたファイルＦ６を
削除することもできるが、この場合に、ファイルＦ６は、Ｔｉｄ２にも他者にも
可視にならないことに留意されたい。そのような作成−削除動作を処理する方法
の１つが、ディレクトリＤ４からエントリを除去し、分離ディレクトリ１７０_２からエントリを除去することである。もう１つの方法は、分離ディレクトリ１７
０_２にエントリを残し、ディスポジションフラグを、作成するＴｉｄ２と他者の
両方に対して不可視にセットし、これによって、Ｔｉｄ２がコミットまたは中断
するまでファイル名が他者によって使用されなくすることである。

【０１４７】トランザクションＴｉｄ２によってＦ６が作成されるが、削除されない、通常
の情況に戻ると、トランザクションＴｉｄ２がコミットまたは中断する時に（そ
の場合に）、分離エントリが、分離ディレクトリ１７０_２から除去され、したが
って、作成されたファイルＦ６が、コミットの場合にどのトランザクションにも
可視にされる。トランザクションＴ２が中断する場合には、ファイルが、通常の
ＮＴＦＳディレクトリＤ４から削除される。各分離エントリは、それに関連する
トランザクションの終了まで残され、コミットまたは中断の時に除去される。除
去を容易にするために、各トランザクションは、そのトランザクションが少なく
とも１つのエントリを有するＴｘＦＳＣＢポインタのリストを維持する。トラン
ザクションはまた、ＴｘＦＳＣＢのそれぞれの参照カウンタを適当に増分または
減分し、その結果、ＴｘＦＳＣＢが、それを使用するトランザクションによって
存在を維持されるようにする。

【０１４８】図２０に、要求がＮｅｗ＿Ｆｉｌｅ＿Ｃｒｅａｔｅ（たとえば、同一のファイ
ル名を有するファイルが既に存在する場合に作成が許可されないタイプの）であ
る場合の、ファイルの作成に関する要求を処理する一般的な論理の表現を示す。
ステップ２０００で開始して、テストを実行して、ファイル名（たとえば図１７
のＦ６）が、普通の親ディレクトリ、たとえば親ディレクトリＤ４に既に存在す
るかどうかを判定する。そうである場合には、ファイルを作成することができず
、ステップ２０００は、ステップ２００２に分岐し、ここでエラーを返す。ファ
イルＦ６が、親ディレクトリＤ４で見つからない場合に、ファイル名が既にトラ
ンザクションによって使用されている可能性がある。これをテストするために、
ステップ２０００は、ステップ２００４に分岐し、ここで、Ｄ４に関連する分離
ディレクトリ１７０_２を、このファイル名について検索する。このファイルＦ６
（または分離ディレクトリ）のエントリが存在しない場合には、ステップ２００
４は、ステップ２００６に分岐し、ここで、トランザクションまたは非トランザ
クションのどちらが作成を要求しているのかに関する判定を行う。非トランザク
ションが要求している場合には、ステップ２００６は、ステップ２０１８に分岐
し、ここで、普通のディレクトリＤ４にファイルを作成する。そうでない場合に
は、トランザクション（たとえばＴｉｄ２）が作成を要求しており、ステップ２
０１０が実行されて、そのファイルのエントリが分離ディレクトリ１７０_２に追
加される（親ディレクトリＤ４についてまだ存在していない場合には分離ディレ
クトリ１７０_２を作成した後に）。その後のステップ２０１４は、適当なフラグ
を設定すること、このエントリに関する他の情報を得ることなどを表す。ステッ
プ２０１４は、ステップ２０１８に継続し、ここで、ファイルＦ６が、実際に普
通のディレクトリＤ４に作成される。ＮＴＦＳでは、作成時に、ファイルが割り
振られ、ファイルレコードがそのファイルのマスタファイルテーブル内で作成さ
れ、作成レコードがログに追加されることに留意されたい。

【０１４９】ステップ２００４で、名前が分離ディレクトリ１７０_２で見つかった場合には
、指定されたファイルが、現在作成を要求しているものと同一のＴｉｄ（たとえ
ばＴｉｄ２）によって削除されない限り、作成は許可されない。このようにして
、トランザクションは、それが削除したファイルを作成することができるが、他
のトランザクションまたは非トランザクションは、ファイルを作成し、かつ／ま
たは削除したトランザクションがコミットするか中断するまで、そのファイル名
を使用することができない。見つかった場合には、ステップ２０１２を実行して
、フラグ状況をテストして、同一のトランザクションが現在作成を要求している
かどうかを判定する。そうである場合には、ステップ２０１２は、ステップ２０
１４に分岐して、このエントリのフラグの状況を変更し、本質的に「Ｔｉｄ２に
よって削除」（Ｔｉｄ２に不可視、おそらく他者に可視）ではなく、「Ｔｉｄ２
によって作成」（Ｔｉｄ２に可視、他者に不可視）を表すようにする。別のトラ
ンザクションまたは非トランザクションが作成を要求している場合には、ステッ
プ２０１２が、ステップ２０１６に分岐して、エラーを返し、トランザクション
がこのファイル名を予約していることを示す。

【０１５０】図１８は、本質的にリンク作成要求とリンク削除要求を組み合わせたものであ
る、トランザクショナルファイル名前変更動作を表す。したがって、トランザク
ションＴ１が、ファイルの名前「＼Ｄ２＼Ｄ３＼Ｆ２」を「＼Ｄ２＼Ｄ３＼Ｄ４
＼Ｆ７」に変更する場合に、リンクＦ２が、ディレクトリＤ３から削除され、リ
ンクＦ７が、ディレクトリＤ４に作成される。しかし、トランザクションが名前
の変更にかかわっているので、この動作は、適当な分離ディレクトリ１７０_３お
よび１７０_４で反映される。ファイルが、同一の親ディレクトリ内で名前を変更
される場合があり、あるいは、ファイルが同一のファイル名を有するが、異なる
ディレクトリにあるように名前を変更される場合があることに留意されたい。

【０１５１】本発明によれば、ファイルのトランザクショナル名前変更に関して、名前変更
に用いられる各親ディレクトリの分離ディレクトリ、たとえば、トランザクショ
ンの削除動作を示す分離ディレクトリ、およびトランザクションの作成動作を示
す分離ディレクトリが提供される。同一の親ディレクトリ内での名前変更が、古
いファイルの削除に関する１エントリと、新しいファイルの作成に関する１エン
トリとを有する１つの分離ディレクトリだけを必要とすることに留意されたい。
上で説明した図１９（削除）および２０（作成）から理解できるように、他のト
ランザクションは、トランザクションがコミットするまで、名前が変更されなか
ったかのようにファイルを見、名前を変更されたファイルを見ない。トランザク
ションが中断する場合には、他のトランザクションは、使用中のファイル名がト
ランザクションの寿命の間に一時的に予約されることを潜在的に見ることを除い
て、名前変更が行われたことを示すものを一切見ない。

【０１５２】最後に、図２１〜２２は、ファイルのオープンまたはそのファイル情報を得る
（たとえば列挙の一部として）ことを試みる時などに、ファイルの状態に応じて
、トランザクションが指定されたファイルを見るか否かを表す。ステップ２１０
０は、ファイルが普通の親ディレクトリにあるかどうかのテストを表す。そうで
ある場合には、分離ディレクトリが存在する場合に、このファイルのエントリに
ついて分離ディレクトリを検索して、ファイルが要求元に可視であるかどうかを
判定する必要がある（ステップ２１０２）。普通のディレクトリにない場合には
、ファイルが、進行中のトランザクションによって普通のディレクトリから削除
された可能性があり、これは、下の図２２で処理される。

【０１５３】ファイルが普通のディレクトリにあり（ステップ２１００）、ステップ２１０
２でファイルのエントリが分離ディレクトリにない場合には、そのファイルは、
普通にアクセス可能なファイルすなわち、まだコミットしていないトランザクシ
ョンによって作成されたものではないファイルである。そうである場合には、フ
ァイルシステムは、トランザクションの前と同様に動作する（ステップ２１０４
によって表される）。すなわち、ファイルハンドルを返すことができ（たとえば
、ファイルオープン要求の場合に）、あるいは、マスタファイルテーブル内の情
報からファイル情報を返すことができる（たとえば、列挙要求の場合に）。

【０１５４】ファイルのエントリが、分離ディレクトリツリーにある場合には、そのファイ
ルは、進行中のトランザクションによって作成されたものである必要があり、ス
テップ２１０２は、ステップ２１０６に分岐し、テストを実行して、ファイルを
作成したトランザクションが、現在アクセスまたはその情報を要求しているトラ
ンザクションと同一であるかどうかを判定する。そうである場合には、ステップ
２１０６は、ステップ２１０８に分岐し、可視性ディスポジションフラグ（この
Ｔｉｄに可視であるかどうか）をテストすることができる。可視の場合には、フ
ァイルハンドル（またはファイル情報）を、要求しているトランザクションに返
す（ステップ２１１０）。本実施形態では、ファイルが普通のディレクトリにあ
り、そのエントリが分離ディレクトリにある（トランザクションによる作成のゆ
えに）が、ファイルを作成したトランザクションにファイルを可視にしてはなら
ないことをフラグが示す情況があってはならないことに留意されたい。したがっ
て、本実施形態では、ステップ２１０８のテストが、普通のディレクトリおよび
／または分離ディレクトリの破損または類似物を検出するのに使用されるのでな
い限り、本質的に不要である。

【０１５５】ファイルのエントリが、普通のディレクトリにあり（ステップ２１００）、分
離ディレクトリツリーにある（ステップ２１０２）が、ステップ２１０６で、同
一のトランザクションが要求を行っているのではないと判定される場合には、本
実施形態では、ファイルが、ステップ２１１４で、他者に可視である場合もそう
でない場合もある。可視でない場合には、ステップ２１１６で、要求の一部とし
て、他のトランザクションがそのファイル名を使用することを要求している場合
に、ファイルが別のトランザクションによって使用中であることを示すエラーが
返されることを除いて、見つからなかったものとしてファイルを扱う。たとえば
、指定されたファイルが見つからない場合に新規ファイルの作成を試みるタイプ
のファイルオープン要求は、名前が使用中なのでエラーになる。ステップ２１１
４で他者に可視である（ファイルが、削除された後に作成された）場合には、リ
ダイレクトＦｉｄを使用して、＄ＴｘＦディレクトリから削除されたファイルを
オープンする（ステップ２１１８）。

【０１５６】図２２では、ファイルが普通のディレクトリにない情況を処理する。まだコミ
ットも中断もしていないトランザクションがファイルを削除した場合には、その
ファイルのエントリが、分離ディレクトリにあり、これによって、そのトランザ
クションはこのファイルを見ることができないが、他者は見ることができる。ス
テップ２２００で、ファイルのエントリが分離ディレクトリにない（かつ、図２
１のステップ２１００を介して普通のディレクトリにない）かどうかをテストし
、ない場合には、ステップ２２０２で、ファイルが見つからず、それに応じて扱
われる。

【０１５７】そうではなく、ステップ２２００で、名前が分離ディレクトリに存在する場合
には、あるトランザクションがそれを削除している。ステップ２２０４で、ファ
イルを削除したのと同一のトランザクションがそのファイルへのアクセス（また
はそれに関する情報）を要求しているかどうかをテストする。そうである場合に
は、ステップ２２０６で、ファイルが、それを削除したトランザクションに可視
ではなく、したがって、見つからない状態（ステップ２２０６）が存在する。な
んらかの理由でファイルがトランザクションに可視である場合には、エラーが存
在することに留意されたい。

【０１５８】ステップ２２０４で、ファイルを削除したものと異なるトランザクションが、
そのファイルへのアクセス（またはそれに関する情報）を要求している場合。ス
テップ２２１２によるテストで、ファイルが他者に可視である場合には、ステッ
プ２２１４で、そのファイルのハンドルまたはファイル情報（以下で説明するよ
うに、保存されたファイルＩＤまたはＦｉｄからの、複製された情報を含む）を
返す。

【０１５９】１つの他の可能性は、進行中のトランザクションが、ファイルを作成し、その
後、削除し、これによって、そのファイルが普通のディレクトリにないことであ
る。上で説明したように、ファイル名は、他者に使用可能として扱われるか、ト
ランザクションのコミットまたは中断のいずれかが発生するまで進行中のトラン
ザクションに予約されるかのいずれかになることができる。前者は、ファイルを
作成したトランザクションがそのファイルを削除する時に、普通のディレクトリ
および分離ディレクトリの両方からファイルのエントリを単純に除去することに
よって達成することができるが、そのようなファイルエントリが分離ディレクト
リから除去される場合に、ステップ２２１２に到達しないことに留意されたい。
後者は、削除の際にファイルを普通のディレクトリから除去するが、分離ディレ
クトリ内のファイルのエントリを残し、どのトランザクションにも不可視である
ことを示すようにフラグをセットすることによって、達成することができる。諒
解されるように、これが可能であるのは、可視性ディスポジションフラグが独立
にセットされる（すなわち、相互排他的ではない）からである。しかし、ファイ
ルが分離ディレクトリに残され、他者に（ならびに、それを作成したトランザク
ションに）不可視とマークされる場合に、ステップ２２１６で、ファイルが見つ
からない状態が存在するが、ファイル名は進行中のトランザクションに予約され
る。

【０１６０】このようにして、本発明は、ＮＴＦＳ照合ルールおよびＮＴＦＳルーチンを使
用して、たとえば照合された順序で次の名前を見つける、照合検索を容易にする
。本発明は、スペース効率がよく、並列読取／書込アクセスを可能にする。

【０１６１】見るものまたは見ないものにおいて、非トランザクションが、単純に、普通の
ディレクトリにあるものを見ることに留意されたい。しかし、既存ファイル名の
使用において、非トランザクションは、トランザクションに予約された名前を使
用することができない。この目的のために、非トランザクションが普通のディレ
クトリに存在しない名前を有するファイルの作成を試みる時に、上で説明したよ
うに、分離ディレクトリが検査される。

【０１６２】上の例および説明に鑑みて、以下の説明で、トランザクションが分離ディレク
トリ内のエントリをどのように使用し、変更するかを示す。まず、ディレクトリ
ＸでＹｉｓＡＶｅｒｙＬｏｎｇＮａｍｅという名前の新しいファイルを作成する
、すなわち、Ｘ＼ＹｉｓＡＶｅｒｙＬｏｎｇＮａｍｅを作成するトランザクショ
ンＴｉｄ１０を検討されたい。分離ディレクトリに、下記の２つのエントリが追
加される。Name: YisAVeryLongName;Tid: 10; (Visible to Tid:TRUE, Visible to others:FALSE);LongName: TRUE;pairedNamePtr: 短い名前のエントリへのポインタ;Reserved : TRUE;Fid: INVALID_ID; 他の複製された情報。Name: YisAVery;LongName: FALSE;pairedNamePtr: 長い名前のエントリへのポインタ.

【０１６３】これによって、Ｘの後続のディレクトリ列挙で、それがＴｉｄ１０以外のトラ
ンザクションによって行われる場合にこれらの名前のどれもが返されないが、非
トランザクションが２つの名前を見ることが保証される。さらに、別のトランザ
クションＴｉｄ２０が、この２つの名前のいずれかの作成またはオープンを試み
る場合に、そのトランザクションが、上の分離構造体から検出される、「ファイ
ルが既に存在するが共有違反」エラーを受け取る。

【０１６４】非被トランザクションスレッドがこの名前のどちらかをオープンする場合に、
そのスレッドは、書込、削除、または他の種類の変更のためにオープンする場合
に、共有違反を受け取る。そのような非トランザクションは、読取専用でオープ
ンすることができる。これは、上で説明したように別に実施される、ＴｘＦのフ
ァイルロッキングセマンティクスに起因する。

【０１６５】第２の例である、親ディレクトリＸからの既存ファイルＹｉｓＡＶｅｒｙＬｏ
ｎｇＮａｍｅの被トランザクション削除を検討されたい。この例では、この名前
に関する短い名前のリンクもディレクトリＸにある（リンク削除の場合ではなく
、名前対の場合）。やはり、トランザクションは、識別子Ｔｉｄ１０を有し、こ
れによって、分離ディレクトリに、下記の２つのエントリが追加される。Name: YisAVeryLongName;Tid: 10; (Visible to Tid:FALSE, Visible to others:TRUE);LongName: TRUE;pairedNamePtr: 短い名前のエントリへのポインタ;Reserved : TRUE;Fid: ファイルId; 他の複製された情報。Name: YisAVery;LongName: FALSE;pairedNamePtr: 長い名前のエントリへのポインタ.

【０１６６】２つのリンクは、ディレクトリＸのインデックスＳＣＢからも削除されるが、
さしあたり、ファイルが物理的に除去されないことをＴｘＦが保証すると仮定す
る。というのは、ＴｘＦが、削除の前にファイルにシステム所有のリンクを追加
するからである。その結果、２つの名前のどちらもが、Ｔｉｄ１０以外のものが
新しいファイルの作成またはリンクに使用することができなくなる。これは、Ｔ
ｉｄ１０が、中断し、名前を再請求することを決定できるからである。また、こ
れらの名前は、ディレクトリ列挙またはＣｒｅａｔｅでＴｉｄ１０に可視でない
が、このＣｒｅａｔｅによって、Ｔｉｄ１０が、２つの名前のいずれかを用いて
新しいリンク／ファイルを作成することができるようになる。これらの名前は、
他のトランザクションに可視であり、これは、他のトランザクションが、ファイ
ルＩＤ（Ｆｉｄ）を使用してそれらをオープンできることを意味する。非被トラ
ンザクションユーザは、これらのファイルを見ることができないが、これらの名
前を新規作成に使用することもできない。

【０１６７】第３の例では、第１の例が前に発生した、すなわち、ファイルが作成されたと
考慮されたい。その後、名前がトランザクションＴｉｄ１０に可視なので、Ｔｉ
ｄ１０は、自由にこのファイルをオープンでき、Ｔｉｄ１０と同様に削除するこ
とができる。したがって、Ｔｉｄ１０が、書込のためにファイルをオープンし、
後にこれを削除した場合に、削除の後の分離エントリは、次のようになる。Name: YisAVeryLongName;Tid: 10; (Visible to Tid:FALSE, Visible to others:FALSE);LongName: TRUE;pairedNamePtr: 短い名前のエントリへのポインタ;Reserved : TRUE;Fid: INVALID_ID; 複製された情報なし。Name: YisAVery;LongName: FALSE;pairedNamePtr: 長い名前のエントリへのポインタ。

【０１６８】これらのエントリでは、トランザクションのために名前が予約されるが、すべ
てに不可視にされる。予約が、ロールバックを動作可能にするために実行される
ことに留意されたい。

【０１６９】浮動化されたメモリマッピングされたセクション本発明のもう１つの態様は、アプリケーションが、書込アクセスのためにオー
プンされた１つまたは複数のファイルに対するメモリマッピングを実行しており
、アプリケーションがその一部であるトランザクションが中断した（またはコミ
ットした）ことを意識しない場合の問題の解決を対象とする。これは、たとえば
、分散トランザクションが、もう１つのノードネットワークノード上で中断した
時に発生する可能性がある。アプリケーションは、そのような時に、不適当にま
たは不当に振る舞う場合もある。

【０１７０】アプリケーションが、書込アクセスのためにオープンされたファイルに対して
メモリマッピングを実行しており、それに関連するトランザクションが中断（ま
たはコミット）したことを意識せず、かつ／または、不適当にまたは不当に振る
舞っている時に、もう１つのライタが、書込アクセスのためにまだメモリマッピ
ングされているファイルをオープンすることができる。その結果、複数の同時ラ
イタ（ｓｉｍｕｌｔａｎｅｏｕｓｗｒｉｔｅｒｓ）が存在する可能性があるの
で、ファイルデータに関する衝突が発生する可能性がある。具体的に言うと、ア
プリケーションによって実行される時に、メモリマッピングは、セクションオブ
ジェクト（共有メモリのブロック）を使用して、ファイルをプロセスアドレス空
間にマッピングすることを指す。アプリケーションがページを修正する場合に、
メモリマネージャが、通常のページング動作中に変更をディスクのファイルに書
き戻すことができ、あるいは、アプリケーションが直接にフラッシュを引き起こ
すことができる。トランザクショナル環境では望ましくないが、アプリケーショ
ンは、メモリマッピングを実行することを許可され、したがって、別のトランザ
クショナルアプリケーションによって書込アクセスのためにオープンされている
ファイルへの書込を引き起こす可能性を有する。

【０１７１】ファイルシステムは、トランザクションがコミットまたは中断する時を知って
おり、たとえば、そのトランザクションによって影響されたデータ構造体をクリ
ーンアップするが、メモリマネージャに照会して、トランザクションのアプリケ
ーションプロセス（の１つまたは複数）がメモリマッピングを行っているか、す
なわち、セクションハンドルを作成したかどうかを判定する。そのようなアプリ
ケーションが存在する場合には、ファイルシステムは、そのアプリケーションの
動作状態を知らず、直接にアプリケーションをシャットダウンすることも、また
はアプリケーションがマッピングされたセクションに書き込み続けないことを保
証することもできない。

【０１７２】図２３に、ファイルシステム６２が、別のアプリケーション１８２によって書
込アクセスのためにオープンされるマッピングされたファイルにアプリケーショ
ン１８０（もはやトランザクションの一部ではない）が書き込まないようにする
方法の１つを示す。この目的のために、ファイルシステムは、セクション制御ブ
ロック（ＳＣＢ）１８８を調整し、その結果、各々のアプリケーション１８０お
よび１８２のファイルオブジェクト１８４および１８６が、別個のセクションオ
ブジェクトポインタ１９０および１９２をポイントするようにする。無効なトラ
ンザクショナルアプリケーション１（１８０）のセクションオブジェクトポイン
タ１９０は、空であるが、有効なトランザクショナルアプリケーション２（１８
２）のセクションオブジェクトポインタ１９２は、そのアプリケーション１８２
のメモリ１９６へのポインタを有する。これによって、メモリセクション１９４
が、浮動化される。

【０１７３】無効なトランザクショナルアプリケーション１８０は、浮動化されたメモリセ
クション１９４から読み取るか、それに書き込むことを継続することができるが
、このメモリセクションは、もはやファイルに対応しない。それと同時に、ペー
ジが、有効なアプリケーション１８２の代わりにファイルシステム６２を介して
キャッシュ／メモリマネージャ１１４によってページがフォールトされる時に、
必ず、適当な仮想メモリページ１９８が（したがって、アプリケーション１８２
によって使用されるメモリ１９６も）、トランザクショナルに正しいファイル、
たとえば、ＴＯＰＳストリームバージョンで維持される正しいページから、また
はディスクのファイルから、適宜データを書き込まれる。ファイルシステム６２
は、同様に、有効なアプリケーションによって変更されたページを、メモリマネ
ージャ１１４による指示に従ってディスク１１２に書き込む。

【０１７４】しかし、無効なアプリケーション１８０にマッピングされたセクション内のペ
ージについて、メモリセクション１９４に対応するファイルシステム６２に達す
るメモリマネージャ１１４からのすべての書込要求が、ファイルシステム６２に
よって受け入れられるが、実際にはディスクに書き込まれない。その結果、マッ
ピングされたメモリが、浮動化されたセクションになり、メモリ内での書込が許
可されるが、その変更は、絶対にディスクにフラッシュされない。メモリマネー
ジャ１１４によるディスク１１２からのページのフォールトインの要求は、０が
そこに返されることをもたらす。その結果、セクション１９４のこのバージョン
は、もはやディスク上のファイルによってバッキングされない。このようにして
、有効なトランザクショナルアプリケーションのファイルデータが、無効なアプ
リケーションによってマッピングされたファイルに対して行われるデータ変更か
ら分離される。

【０１７５】代替案では、メモリのマッピングされたセクションを、無効なアプリケーショ
ンに対してアクセスなしまたは読取専用に変更し、これによって、無効なアプリ
ケーションによるそれへの書込がアクセス違反を引き起こすようにすることが可
能である。読取が許容される場合には、無効なアプリケーションは、有効なアプ
リケーションによって行われた変更がセクション１９４にフォールトされる時に
、必ず、そのような変更を見ることができる。

【０１７６】上の解決策のどれもが、無効なアプリケーション１８０のクラッシュを引き起
こす可能性があるが、有効なアプリケーション１８２のデータが、正しく分離さ
れることに留意されたい。無効なアプリケーション１８０のクラッシュを避ける
ために、それによって行われた変更を、ディスクの別のファイルに書き込むこと
ができるが、現在、そのようなポストトランザクションバージョンのサポートは
、そのようなアプリケーションに関して無用にコストが高いと見なされている。

【０１７７】ＴｘＦログレコードフォーマット // 回復マネージャに既知のログレコードタイプ typedef enum { TxfLogRecTypeRedo, TxfLogRecTypeUndo, TxfLogRecTypePrepare, TxfLogRecTypeAbort, TxfLogRecTypeCommit, } TXF_LOGREC_TYPE; typedef enum { TxfLogRecActionCreateFile, TxfLogRecActionDeleteFile, TxfLogRecActionWriteFile, TxfLogRecActionOverwriteFile, TxfLogRecActionFcbInfoUpdateFile, TxfLogRecActionTemporaryBitChangeFile, TxfLogRecActionUpdateDupInfo, TxfLogRecActionTruncateFile, TxfLogRecActionRestoreFileSizes, TxfLogRecActionCancelRecord, TxfLogRecActionTestPrint } TXF_LOGREC_ACTION; typedef struct { TXF_LOGREC_TYPE Type; TXF_LOGREC_ACTION Action; TXF_TRANS_ID TransId; } TXF_LOGREC, *PTXF_LOGREC; /* typedef struct { TXF_LOGREC_HDR header; char data[1]; } TXF_LOGREC, *PTXF_LOGREC; */ // // 削除ファイルログレコード。 // // // 長い名前および短い名前は、レコードの直後に配置される。 // typedef struct _TXF_DELETE_FILE_UNDO_LOGREC { TXF_LOGREC Header; // // フラグの値については下を参照 // USHORT Flags; // // 短い名前がない場合にはShortNameLengthは０。 // 短い名前は、FileName.FileNameが終わった // 直後から始まる。これは、 // PWCHAR FileName.FileName + // FileName.FileNameLengthにある。 // ShortNameLengthはユニコード文字内である。 // USHORT ShortNameLength; // // 名前の変更が行われたMungedFileNumber。 // ULONG MungedFileNumber; // // 名前の変更が行われたTxfサブディレクトリ。 // ULONG SubDirNumber; // // 有効な複製された情報、親ディレクトリ、長さなどを伴う // 長い／組み合わされた名前。 // FILE_NAME FileName; // // この後にフィールドを追加してはならない。 // } *PTXF_DELETE_FILE_UNDO_LOGREC, TXF_DELETE_FILE_UNDO_LOGREC; // // ファイルがディレクトリの場合に真。 // #define TXF_DELETE_FILE_UNDO_FLAGS_DIRECTORY 0x01 // // この削除動作でFidフラグが保管された場合に真。 // #define TXF_DELETE_FILE_UNDO_FLAGS_FID_STORED 0x02 // // 削除のために名前をオープンしたCCBのIgnoreCaseフラグ。 // #define TXF_DELETE_FILE_UNDO_FLAGS_IGNORE_CASE 0x04 // // Create-Fileアンドゥログレコード。 // // 長い名前および短い名前は、レコードの直後に配置される。 // typedef struct _TXF_CREATE_FILE_UNDO_LOGREC { TXF_LOGREC Header; FILE_REFERENCE ParentFid; // // LongNameLengthはユニコード文字内。 // USHORT LongNameLength; // // LongNameOffset = sizeof(struct // _TXF_CREATE_FILE_UNDO_LOGREC) // // // フラグの値については下を参照 // USHORT Flags; // // ShortNameLength は、短い名前がない場合に０。 // Lengthはユニコード文字内。 // USHORT ShortNameLength; // // ShortNameOffsetはsizeof(struct // _TXF_CREATE_FILE_UNDO_LOGREC）+ // LongNameLength*sizeof(WCHAR)である。 // USHORT Reserved1; ULONG Reserved2; } *PTXF_CREATE_FILE_UNDO_LOGREC, TXF_CREATE_FILE_UNDO_LOGREC; // // ファイルがディレクトリである場合に真。 // #define TXF_CREATE_FILE_UNDO_FLAGS_DIRECTORY 0x01 // // 名前を作成したCCBのIgnoreCaseフラグ。 // #define TXF_CREATE_FILE_UNDO_FLAGS_IGNORE_CASE 0x02 // // Overwrite-Fileアンドゥログレコード。 // typedef struct _TXF_OVERWRITE_FILE_UNDO_LOGREC { TXF_LOGREC Header; // // 上書きされたファイルのファイル参照 // FILE_REFERENCE Fid; // // TxFディレクトリに作成されたTxFファイルのファイル参照。 // FILE_REFERENCE TxfFileFid; // // TxFディレクトリに作成されたTxFファイルのMungedFileNumber。 // ULONG MungedFileNumber; // // TxFファイルが作成されたTxFサブディレクトリ。 // ULONG SubDirNumber; USHORT Flags; USHORT Reserved1; ULONG Reserved2; } *PTXF_OVERWRITE_FILE_UNDO_LOGREC, TXF_OVERWRITE_FILE_UNDO_LOGREC; // // FcbInfoUpdateアンドゥログレコード。これは、 // 標準情報のTxfLsnを検査せずに無条件に元に戻される。 // typedef struct _TXF_FCB_INFO_UPDATE_UNDO_LOGREC { TXF_LOGREC Header; // // 上書きされたファイルのファイル参照 // FILE_REFERENCE Fid; // // アンドゥ際に復元されるFcb情報。 // DUPLICATED_INFORMATION FcbInfo; } *PTXF_FCB_INFO_UPDATE_UNDO_LOGREC, TXF_FCB_INFO_UPDATE_UNDO_LOGREC; // // FcbInfoUpdateアンドゥログレコード。これは // 標準情報のTxfLsnを検査せずに無条件で元に戻される。 // typedef struct _TXF_TEMPORARY_BIT_CHANGE_UNDO_LOGREC { TXF_LOGREC Header; // // 上書きされたファイルのファイル参照 // FILE_REFERENCE Fid; ULONG PreviousBitValue; // // デフォルトデータストリームの場合に、属性名長さは０。 // Lengthはユニコード文字内。 // 属性名は、存在する場合にログレコードに続く。 // USHORT AttrNameLength; WCHAR AttrName[1]; } *PTXF_TEMPORARY_BIT_CHANGE_UNDO_LOGREC, TXF_TEMPORARY_BIT_CHANGE_UNDO_LOGREC; // // UpdateDupInfoアンドゥログレコード。 // // 長い名前は、レコードの直後に配置される。 // typedef struct _TXF_UPDATE_DUPINFO_UNDO_LOGREC { TXF_LOGREC Header; // // 親ディレクトリのFid。 // FILE_REFERENCE ParentFid; // // LongNameLengthはユニコード文字内。 // USHORT LongNameLength; // // フラグの値については下を参照。 // USHORT Flags; // // 複製された情報。 // DUPLICATED_INFORMATION DupInfo; WCHAR LongName[1]; } *PTXF_UPDATE_DUPINFO_UNDO_LOGREC, TXF_UPDATE_DUPINFO_UNDO_LOGREC; #define TXF_UPDATE_DUPINFO_UNDO_FLAGS_DIRECTORY 0x0001 // // Truncateアンドゥログレコード。 // // 属性名は、レコードの直後に配置される。 // typedef struct _TXF_TRUNCATION_UNDO_LOGREC { TXF_LOGREC Header; // // ファイルのFid。 // FILE_REFERENCE Fid; LONGLONG ValidDataLength; LONGLONG FileSize; // // デフォルトデータストリームの場合に、属性名長さは０。 // Lengthはユニコード文字内。 // 属性名は、存在する場合にログレコードに続く。 // USHORT AttrNameLength; WCHAR AttrName[1]; } *PTXF_TRUNCATION_UNDO_LOGREC, TXF_TRUNCATION_UNDO_LOGREC; // // Restore file sizesアンドゥログレコード。 // // 属性名は、レコードの直後に配置される。 // typedef struct _TXF_RESTORE_FILE_SIZES_UNDO_LOGREC { TXF_LOGREC Header; // // ファイルのFid。 // FILE_REFERENCE Fid; LONGLONG ValidDataLength; LONGLONG FileSize; // // デフォルトデータストリームの場合に、属性名長さは０。 // Lengthはユニコード文字内。 // 属性名は、存在する場合にログレコードに続く。 // USHORT AttrNameLength; WCHAR AttrName[1]; } *PTXF_RESTORE_FILE_SIZES_UNDO_LOGREC, TXF_RESTORE_FILE_SIZES_UNDO_LOGREC; // // 変更テーブルエントリのフォーマットおよび関連する // 定数を定義する。 // #define TOPS_SECTOR_SIZE (512) #define TOPS_PAGE_SIZE (4096) #define TOPS_PAGE_SHIFT (12) #define TOPS_SECTORS_PER_PAGE (TOPS_PAGE_SIZE / TOPS_SECTOR_SIZE) #define TOPS_MAXIMUM_FLUSH_SIZE (0x10000) typedef struct _CHANGE_ENTRY { // // これらの２つのフィールドは、ストリームの置換された範囲の // 仮想アドレスを記述する。 // ULONGLONG VirtualPageNumber; ULONG NumberPages; // // これは、古いページが書き込まれたTopsストリーム内の // 開始ページ番号である。 // ULONG TopsPageNumber; // // これは、この変更を記述したログレコードのLsnである。 // CLFS_LSN Lsn; // // この変更に含まれるアンドゥページのすべてのバイトに // SequenceNumberが書き込まれる。 // UCHAR SequenceNumber; // // サイズが必ず４ワードに丸められるので、位置合せ用の // 予約バイトをここに置いてもよい。 // UCHAR Reserved[7]; // // 最後に、これらは、データの置換されたバイトであり、 // Topsストリーム内の引き裂かれた書込の検出を可能にする。 // １ページに十分なメモリが割り当てられるが、 // NumberPagesが１以上の場合に追加のバイトが割り当てられる。 // UCHAR DisplacedBytes[TOPS_SECTORS_PER_PAGE]; } CHANGE_ENTRY, *PCHANGE_ENTRY; // // Create-Fileアンドゥログレコード。 // // 長い名前および短い名前は、レコードの直後に配置される。 // typedef struct _TXF_WRITE_FILE_UNDO_LOGREC { TXF_LOGREC Header; // // アンドゥデータがそこから取り込まれたファイルのファイル参照。 // FILE_REFERENCE FileReference; // // アンドゥデータがどこに書き込まれるかを記述し、 // シーケンス番号に置換されたバイトを保管する。 // CHANGE_ENTRY ChangeEntry; } TXF_WRITE_FILE_UNDO_LOGREC, *PTXF_WRITE_FILE_UNDO_LOGREC;

【０１７８】前述の詳細な説明からわかるように、アプリケーションが１つまたは複数のフ
ァイルに対して複数のトランザクショナル動作を簡単に実行できるようにするト
ランザクショナルファイルシステムおよび方法が提供される。複数のファイルシ
ステム動作が、ファイルシステム内でトランザクショナルな形で一緒に結び付け
られ、動作が、一緒にコミットされるか、すべての部分的なアクションが元に戻
されるかのいずれかになる。さらに、あるトランザクションの動作およびデータ
変更が、別のトランザクションの動作およびデータから分離される。したがって
、たとえば、本発明は、素早く効率的で安全な形で、ファイルシステムコンポー
ネントによって処理される単一のトランザクションとしてウェブサイトを更新す
ることができる。それと同時に、進行中の変更が、トランザクションがコミット
するまで他者から分離される。

【０１７９】本発明は、さまざまな修正構成および代替構成の余地があるが、ある例示の実
施形態が、図面に示され、上で詳細に説明された。しかし、開示された特定の形
態に本発明を制限する意図はなく、逆に、本発明は、本発明の趣旨および範囲に
含まれるすべての修正構成、代替構成、および均等物を含むことを理解されたい
。

【図面の簡単な説明】

【図１】本発明を組み込むことができるコンピュータシステムを表すブロック図である
。

【図２】本発明の一態様によるトランザクショナルファイルシステムを実施する一般的
なアーキテクチャを表すブロック図である。

【図３】本発明の一態様による、トランザクション処理されるファイルの作成／オープ
ンに関する要求を表すブロック図である。

【図４】本発明の一態様による、オープンされたトランザクション処理されるファイル
に対してファイルシステム動作を実行する要求を表すブロック図である。

【図５】本発明の一態様による、ある時間の期間にわたるトランザクション処理される
ファイルの分離を表すブロック図である。

【図６】本発明の一態様による、ファイルバージョンを追跡するデータ構造体を表すブ
ロック図である。

【図７】本発明の一態様による、経時的に維持される複数のファイルバージョンを表す
ブロック図である。

【図８】トランザクショナルにオープンされたファイルのデータの、書き込まれるペー
ジを表すブロック図である。

【図９】本発明の一態様による、トランザクションでの読取アクセスおよび書込アクセ
スのためにオープンされたファイルの分離をサポートするデータ構造体の間の関
係を表すブロック図である。

【図１０】本発明の一態様による、トランザクションでの読取アクセスおよび書込アクセ
スのためにオープンされたファイルの分離をサポートするデータ構造体の間の関
係を表すブロック図である。

【図１１】本発明の一態様による、２レベルログ記録機構およびログが同期化されている
かどうかを検証する機構を表すブロック図である。

【図１２】本発明の一態様による、ログ記録されるページデータと、ページデータがログ
と同期化されているかどうかを検証する機構を表すブロック図である。

【図１３】本発明の一態様による、ページデータがログ記録されたレコードと同期化され
ているかどうかに基づいて行われるアクションを表す流れ図である。

【図１４】本発明の一態様による、代替バージョン管理法式で経時的に維持される複数の
ファイルバージョンを表すブロック図である。

【図１５】本発明の一態様による、ネットワークを介するトランザクショナルファイルシ
ステム動作を表すブロック図である。

【図１６】本発明の一態様による、名前空間分離をもたらす階層ファイル構造および分離
ディレクトリの使用を表すブロック図である。

【図１７】本発明の一態様による、名前空間分離をもたらす階層ファイル構造および分離
ディレクトリの使用を表すブロック図である。

【図１８】本発明の一態様による、名前空間分離をもたらす階層ファイル構造および分離
ディレクトリの使用を表すブロック図である。

【図１９】本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関
する一般的なルールを示す流れ図である。

【図２０】本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関
する一般的なルールを示す流れ図である。

【図２１】本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関
する一般的なルールを示す流れ図である。

【図２２】本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関
する一般的なルールを示す流れ図である。

【図２３】本発明の一態様による、メモリマッピングされたセクションの浮動化を表すブ
ロック図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者トーマスジェイ．ミラーアメリカ合衆国 98004 ワシントン州ベルビューノースイースト 47 ストリート 9015 (72)発明者ロバートジー．アトキンソンアメリカ合衆国 98072 ワシントン州ウッディンビルノースイースト 196 ストリート 17926 Ｆターム(参考） 5B082 GB06 【要約の続き】回復を容易にする複数レベルログでの名前空間ログ記録動作も処理する。ページデータもまた、メインログと別にログ記録され、システムクラッシュの前にページが完全にディスクにフラッシュされたかどうかをログが判定できるようにする一意の署名を有する。名前空間分離は、トランザクションが分離ディレクトリを介してコミットするまで提供され、これによって、コミットされるまでは、トランザクションが、それ自体の動作の影響を見るが、他のトランザクションの動作の影響は見ない。ネットワーク上のトランザクションも、リダイレクタプロトコルを介して容易にされる。

Claims

【特許請求の範囲】

【請求項１】コンピュータ実行可能命令を有するコンピュータ可読媒体で
あって、ファイルが第１トランザクションに関連することを示す情報をファイルシステ
ムで受け取り、ファイルに対する名前空間関連動作を実行する第１要求をファイルシステムで
受け取り、前記ファイルに関する情報を分離ディレクトリに保管し、前記ファイルに向けられた第２要求を受け取り、前記ファイルが前記第２要求に関して存在するかどうかを判定するために前記
分離ディレクトリにアクセスするコンピュータ実行可能命令を備えることを特徴
とするコンピュータ可読媒体。
【請求項２】前記第１トランザクションが完了したことの情報を受け取り
、前記分離ディレクトリに保管された前記ファイル情報を除去するコンピュータ
実行可能命令をさらに含むことを特徴とする請求項１に記載のコンピュータ可読
媒体。
【請求項３】前記第１要求は、前記第１トランザクションからの、前記フ
ァイルを削除する要求を含み、前記ファイルが親ディレクトリを有し、前記分離
ディレクトリは、前記親ディレクトリに関連することを特徴とする請求項１に記
載のコンピュータ可読媒体。
【請求項４】前記第１トランザクションがコミットしたことの情報を受け
取り、前記分離ディレクトリ内に保管された前記ファイル情報を除去するコンピ
ュータ実行可能命令をさらに含むことを特徴とする請求項３に記載のコンピュー
タ可読媒体。
【請求項５】前記第１トランザクションが中断したことの情報を受け取り
、前記分離ディレクトリ内に保管された前記ファイル情報を除去し、前記ファイ
ルの前記親ディレクトリにファイル情報を保管するコンピュータ実行可能命令を
さらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
【請求項６】前記第２要求は、前記第１トランザクションからのファイル
情報に関する要求を備え、前記分離ディレクトリへのアクセスは、前記ファイル
が前記第１トランザクションに関して存在しないことを判定することを特徴とす
る請求項１に記載のコンピュータ可読媒体。
【請求項７】前記第２要求は、第２トランザクションからの、前記ファイ
ルへのアクセスの要求を備え、前記分離ディレクトリへのアクセスは、前記ファ
イルが前記第２トランザクションに関して存在することを判定することを特徴と
する請求項１に記載のコンピュータ可読媒体。
【請求項８】ファイルハンドルを前記第２トランザクションに返すコンピ
ュータ実行可能命令をさらに有することを特徴とする請求項７に記載のコンピュ
ータ可読媒体。
【請求項９】ファイルメタデータ情報を前記第２トランザクションに返す
コンピュータ実行可能命令をさらに含むことを特徴とする請求項７に記載のコン
ピュータ可読媒体。
【請求項１０】前記ファイルは、親ディレクトリに関連し、前記分離ディ
レクトリを作成し、前記分離ディレクトリを前記親ディレクトリに関連付けるコ
ンピュータ実行可能命令をさらに含むことを特徴とする請求項１に記載のコンピ
ュータ可読媒体。
【請求項１１】前記第１要求は、前記第１トランザクションからの、親デ
ィレクトリ内で前記ファイルを作成する要求を備えることを特徴とする請求項１
に記載のコンピュータ可読媒体。
【請求項１２】前記第１トランザクションがコミットされたことを示す情
報を受け取り、前記分離ディレクトリ内に保管された前記ファイル情報を除去し
、ファイル情報を前記ファイルの前記親ディレクトリに保管するコンピュータ実
行可能命令をさらに含むことを特徴とする請求項１１に記載のコンピュータ可読
媒体。
【請求項１３】前記第１トランザクションが中断したことを示す情報を受
け取り、前記分離ディレクトリに保管された前記ファイル情報を除去するコンピ
ュータ実行可能命令をさらに含むことを特徴とする請求項１１に記載のコンピュ
ータ可読媒体。
【請求項１４】前記第２要求は、第２トランザクションからのファイル情
報に関する要求を備え、前記分離ディレクトリへのアクセスは、前記ファイルが
前記第２トランザクションに関して存在しないことを判定することを特徴とする
請求項１１に記載のコンピュータ可読媒体。
【請求項１５】前記第２要求は、前記第１トランザクションからの前記フ
ァイルにアクセスする要求を備え、前記分離ディレクトリへのアクセスは、前記
ファイルが前記第１トランザクションに関して存在することを判定することを特
徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１６】前記第２要求は、前記第１トランザクションからのファイ
ル情報に関する要求を備え、前記分離ディレクトリへのアクセスは、前記ファイ
ルが前記第１トランザクションに関して存在することを判定することを特徴とす
る請求項１１に記載のコンピュータ可読媒体。
【請求項１７】前記第２要求に応答して、前記第１トランザクションにフ
ァイルメタデータ情報を返すコンピュータ実行可能命令をさらに含むことを特徴
とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】ファイルを維持する方法であって、ファイルシステム上で第１ファイルシステム動作を実行する第１要求を、前記
ファイルシステムで受け取り、前記第１要求はトランザクションに関連すること
、前記第１ファイルシステム動作を実行すること、前記第１ファイルシステム動作が前記トランザクションに関連することを示す
、前記ファイルシステムからアクセス可能な情報を維持すること、および、前記トランザクションがコミットする場合に、前記第１ファイルシステム動作
をコミットすることを備えることを特徴とする方法。
【請求項１９】前記ファイルシステムで、前記トランザクションがコミッ
トしたことを示す情報を受け取ることをさらに備えることを特徴とする請求項１
８に記載の方法。
【請求項２０】前記トランザクションがコミットしない場合に、前記第１
ファイルシステム動作を元に戻すことを特徴とする請求項１８に記載の方法。
【請求項２１】前記第１ファイルシステム動作は、ファイルを作成するこ
とを備えることを特徴とする請求項１８に記載の方法。
【請求項２２】前記第１ファイルシステム動作は、ファイルを削除するこ
とを備えることを特徴とする請求項１８に記載の方法。
【請求項２３】前記第１ファイルシステム動作は、ファイルの名前を変更
することを備えることを特徴とする請求項１８に記載の方法。
【請求項２４】前記第１ファイルシステム動作に対応する情報を少なくと
も１つのログにログ記録することをさらに備えることを特徴とする請求項１８に
記載の方法。
【請求項２５】前記トランザクションがコミットしない場合に、前記少な
くとも１つのログにアクセスすること、および、前記少なくとも１つのログ内の
前記情報に基づいて前記第１ファイルシステム動作を元に戻すことを特徴とする
請求項２４に記載の方法。
【請求項２６】前記トランザクションが中断したことを示す情報を前記フ
ァイルシステムで受け取ること、および、それに応答して、前記第１ファイルシ
ステム動作を元に戻すことをさらに備えることを特徴とする請求項１８に記載の
方法。
【請求項２７】前記第１ファイルシステム動作をコミットすることは、前
記第１ファイルシステム動作が前記トランザクションに関連することを示す情報
を変更することを含むことを特徴とする請求項１８に記載の方法。
【請求項２８】前記ファイルシステム上で第２ファイルシステム動作を実
行する第２要求を前記ファイルシステムで受け取り、前記第２要求は前記トラン
ザクションに関連すること、前記第２ファイルシステム動作を実行すること、前
記第２ファイルシステム動作が前記トランザクションに関連することを示す、前
記ファイルシステムからアクセス可能な情報を維持すること、および、前記トラ
ンザクションがコミットする場合に、前記第２ファイルシステム動作をコミット
することをさらに備えることを特徴とする請求項１８に記載の方法。
【請求項２９】前記第１ファイルシステム動作は、ファイルをオープンす
ることを備えることを特徴とする請求項１８に記載の方法。
【請求項３０】前記トランザクションに関連するファイルのバージョンを
維持することをさらに含むことを特徴とする請求項２９に記載の方法。
【請求項３１】ファイルへのアクセスを提供する方法であって、ファイルをオープンする第１要求を受け取り、前記要求が第１トランザクショ
ンに関連すること、前記ファイルの第１インスタンスをオープンし、前記ファイルの前記第１イン
スタンスは前記第１トランザクションに関連することを示す情報を維持すること
、前記ファイルをオープンする第２要求を受け取ること、前記ファイルの第２インスタンスをオープンすること、前記ファイルの前記第２インスタンスのデータに対する変更を受け取ること、前記第１インスタンスに対応する前記ファイルの第１バージョンを、前記第２
インスタンスに関連する前記ファイルの第２バージョンから分離するためにデー
タを維持すること、前記ファイルを読み取る読取要求を受け取り、前記読取要求は前記第１トラン
ザクションに関連すること、前記ファイルの前記第１バージョンが第１トランザクションに関連することを
判定すること、および、前記読取要求に応答して、前記ファイルの前記第１バージョンに対応するデー
タを読み取ることを備えることを特徴とする方法。
【請求項３２】前記ファイルの前記第１バージョンを前記ファイルの前記
第２バージョンから分離するためにデータを維持することは、前記ファイルの前
記第１バージョンのデータから別個の前記ファイルの前記第２バージョンの前記
データに対する前記変更を維持することを含むことを特徴とする請求項３１に記
載の方法。
【請求項３３】データに対する前記変更を受け取ることに応答して前記フ
ァイルに変更を書き込むことをさらに備え、前記ファイルの前記第１バージョン
のデータから別個の前記ファイルの前記第２バージョンの前記データに対する前
記変更を維持することは、前記変更を前記ファイルに書き込む前に、前記ファイ
ルの前記第１バージョンの部分のコピーを第１データ構造体に保存することを含
むことを特徴とする請求項３２に記載の方法。
【請求項３４】前記ファイルの第１バージョンを前記ファイルの第２バー
ジョンから分離するためにデータを維持することは、前記部分の前記コピーの位
置をマッピングするために第２データ構造体を維持することを含むことを特徴と
する請求項３３に記載の方法。
【請求項３５】前記部分は、少なくとも１つのページに対応し、前記第２
データ構造体は、変更に対応する各ページ番号を記録することを特徴とする請求
項３４に記載の方法。
【請求項３６】前記読取要求に応答して前記ファイルの前記第１バージョ
ンに対応するデータを読み取ることは、前記読取要求に対応する前記第１データ
構造体内の前記ファイルデータの少なくとも１つの位置を判定するために前記第
２データ構造体にアクセスすることを含むことを特徴とする請求項３４に記載の
方法。
【請求項３７】前記データに対する前記変更に対応する情報をログ内のレ
コードにログ記録することをさらに備え、前記第２データ構造体は前記レコード
を識別する情報をさらに含むことを特徴とする請求項３４に記載の方法。
【請求項３８】前記第２要求は、第２トランザクションに関連することを
特徴とする請求項３１に記載の方法。
【請求項３９】前記ファイルをオープンする前記第１要求は、読取専用要
求に対応することを特徴とする請求項３１に記載の方法。
【請求項４０】前記ファイルをクローズするクローズ要求を受け取り、前
記クローズ要求は前記第１トランザクションに関連すること、前記第１トランザ
クションに関して前記ファイルをクローズすること、前記ファイルをオープンす
る第３要求を受け取り、前記第３要求は前記第１トランザクションに関連するこ
と、前記第１トランザクションから、前記ファイル内のデータにアクセスする要
求を受け取ること、および、データにアクセスする前記要求に応答して、前記第
２バージョンに対応する前記ファイル内のデータにアクセスすることをさらに備
えることを特徴とする請求項３１に記載の方法。