JP4685488B2 - リアルタイムなファイルシステム修復の方法及び記録媒体 - Google Patents

Description

本発明は、リアルタイムなファイルシステム修復の方法及び記録媒体に関する。より詳細には、本発明は、実行中のボリューム（running volume）上で検出された破損のリアルタイムな修正をサポートするファイルシステムに関連した、リアルタイムなファイルシステム修復の方法及び記録媒体並びにコンピュータに関する。

コンピュータにおけるファイルシステムは、コンピュータのストレージボリューム（例えば、ハードディスク）上にデータファイルが格納される仕方を指定し、どのようにファイルがそのボリュームから取り出されるかを指定する。例えば、Ｗｉｎｄｏｗｓ（登録商標）ベース、ＯＳ／２（商標）ベース、Ｍａｃｉｎｔｏｓｈベース（商標）、およびＵＮＩＸ（登録商標）ベースのオペレーティングシステム群は、ファイルを保持するために階層構造またはツリー構造を使用するファイルシステムを有する。ファイルシステムは、ファイル名でいくつの文字を使用することができるか、ファイル名でいずれの文字を使用することができるか、ファイル名のサフィックス（suffix）でいくつの文字が許されるかなど、ファイルに名前を付けることに関する規約も指定する。

「ファイルシステム」という用語は、しばしば、ファイルシステム構造、ファイルシステム規約、および関連するタスクを管理するオペレーティングシステムのファイルシステムドライバ、ファイルシステムプログラム、またはファイルシステム部分を指すのに使用される。このため、ファイルシステムは、異なるユーザ／アプリケーション要求に応答して、ファイルを開くこと、ファイルを読み取ること、ファイルを書き込むこと、ファイルの名前を変更すること、およびファイルを閉じることなどのファイル操作を実行する。ファイルシステムトランザクションを管理することの１つの重要な態様は、ファイルシステム内の内部整合性を維持することである。一般に、ファイルシステムは、ハードディスク（すなわち、ストレージボリューム）上のデータ構造が、全体的なファイルシステムフォーマットに適合し、準拠しているものと見込む。例えば、データが、特定のフォーマットでディスクに書き込まれた場合、ファイルシステムは、そのデータが、同一のフォーマットでディスクから読み出されることが可能であるべきものと見込む。しかし、ディスク上のデータの破損を生じさせることが可能な様々な状況が存在する。ディスク（すなわち、物理記憶媒体）に生じた問題により、例えば、データビットの低下がもたらされる可能性がある。データが、ディスクに正しく書き込まれないこと、またはディスクから正しく読み出されないことをもたらす、コンピュータとハードディスクの間における接続障害が存在する可能性がある。データが、メモリ内のランダムな場所に書き込まれることをもたらす、オペレーティングシステムまたはドライバにおけるプログラミングバグが存在する可能性がある。このため、データ伝送に生じる様々な問題、およびその他の問題が、ファイルシステムのデータ構造の破損を生じさせる可能性がある。

ファイルシステムは、通常、誤ったトランザクション、または不完全なトランザクションによって生じさせられる破損をチェックし、修正するプロセスを使用する。例えば、ワシントン州レッドモンド所在のＭｉｃｒｏｓｏｆｔ（登録商標）コーポレーションからの様々なＷｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステムによって使用されるＮＴＦＳ（Ｎｅｗ Ｔｅｃｈｎｏｌｏｇｙ Ｆｉｌｅ Ｓｙｓｔｅｍ）ファイルシステムは、ボリュームをスキャンして、データ構造に矛盾がない（ｃｏｎｓｉｓｔｅｎｔ）こと、および破損が存在しないことを確実にするＡｕｔｏｃｈｋ／Ｃｈｋｄｓｋユーティリティを使用する。Ａｕｔｏｃｈｋ／Ｃｈｋｄｓｋユーティリティは、ＮＴＦＳボリュームがシステムにマウントされるたびに、ＮＴＦＳボリュームに対して実行され、マウントは、最も一般的に、システムが起動される、または再起動される際に行われる。ＮＴＦＳは、実行中のボリューム上で破損問題を検出すると、そのボリュームに「ダーティ（ｄｉｒｔｙ）」というマークを付け、破損エラーをユーザに提示する。システムが再起動され、ＮＴＦＳが「ダーティな」ボリューム、または他の矛盾を見つけた場合、Ａｕｔｏｃｈｋ／Ｃｈｋｄｓｋが自動的に実行され、ボリュームをマウントするブート要求が遅延されるか、または拒否される。Ｃｈｋｄｓｋユーティリティは、例えば、このユーティリティが実行される時間帯を制限することを所望する大型コンピュータシステムのシステム管理者により、手動で開始されることも可能である。ボリュームに対してＣｈｋｄｓｋが実行されている（すなわち、修復のためにボリュームをスキャンしている）間、ユーザは、そのボリュームにアクセスすることができない。見つかった破損のタイプに応じて、Ｃｈｋｄｓｋは、特定の修正アクションを行って破損を修復することができる。例えば、ファイルがどこに割り当てられているかを示すはずのディスク上の情報に矛盾がある、または破損している場合、Ｃｈｋｄｓｋは、そのファイルを削除する。読み取ることができない、または壊れたファイルディレクトリが存在する場合、Ｃｈｋｄｓｋは、そのディレクトリを再構築する。

そのようなファイルシステム回復ユーティリティ（例えば、Ｃｈｋｄｓｋ）は、一般に、ファイルシステム破損をうまく修復することができるが、欠点を有する。１つの欠点は、そのようなユーティリティが、前述したとおり、ユーザに妨げとなる可能性があることである。Ｃｈｋｄｓｋは、実行するのに長い時間がかかる可能性があり、スキャンし、修復しているボリューム（例えば、ハードディスク）に対する排他的なアクセスを要求する。このため、コンピュータを起動すると、ユーザは、ボリュームにアクセスできず、代わりに、Ａｕｔｏｃｈｋ／Ｃｈｋｄｓｋが修復を終えるのを待ってからでないと、起動プロセスが完了されることが可能でない可能性がある。例えば、企業システムにサービスを提供する大型サーバ上で、Ａｕｔｏｃｈｋ／Ｃｈｋｄｓｋを実行するのにかかる時間は、相当に長い可能性がある。大型サーバは、Ａｕｔｏｃｈｋ／Ｃｈｋｄｓｋで処理するのに数時間（例えば、１０〜１５時間）かかる可能性がある数百万のファイルを有する可能性がある。このため、管理者が、Ａｕｔｏｃｈｋ／Ｃｈｋｄｓｋが実行される時刻に慎重でないと、多くのユーザが不都合を被る可能性がある。

いくつかの文献に上述のような従来の技術に関連した技術内容が開示されている（例えば、特許文献１、２参照）。

米国特許第５、８７５、４４４号明細書 米国特許第６、６４０、３１７号明細書

したがって、ボリュームへのアクセスを妨げる、または阻止することなしに、ボリューム上のファイルシステム破損を修復する仕方の必要性が存在する。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、ファイルシステム破損のリアルタイムな修正を可能にする、リアルタイムなファイルシステム修復の方法及び記録媒体を提供することにある。

システムおよび方法が、ファイルシステム破損のリアルタイムな修正を可能にする。ファイルシステムの拡張機能（ｅｎｈａｎｃｅｍｅｎｔ）が、実行中のボリューム上で検出されたファイルシステム破損にリアルタイムで応答し、ボリューム上の他の操作が継続されることが可能であるようにボリューム全体をロックすることなしに、ファイルシステムが破損を検出した時点で、破損を修復する。ファイルシステムによって破損が検出されると、システム拡張機能は、破損の性質を記述する情報を記録する。見つかった各タイプの破損に関して修復スキャンが定義される。修復は、破損の複雑さに依存して、破損を検出したユーザ要求と同期に、または非同期に行われることが可能である。非同期に行われる場合、アプリケーションは、進行中の修復について知らされる。

本発明によれば、ファイルシステム破損のリアルタイムな修正を可能にする効果を奏する。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。すべての図面で、同様のコンポーネントまたは特徴を指すのに同一の符号を使用する。

［序論］
以下の説明は、実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムおよび方法を対象とする。ファイルシステムは、ファイルシステムが、ほぼ中断されない形でファイルシステム動作を管理することを続けながら、破損を検出し、その破損を修正するための適切な修復を決めるという点で、自己修正型である。ボリュームは、修復処理（ｒｅｐａｉｒ ｏｐｅｒａｔｉｏｎ）中、オンラインで，アクティブなままである。

拡張されたファイルシステムの利点には、破損が、起動時に、または管理者によって設定された特定の時点で実行される修復ユーティリティによってすべて一斉に修復されるのではなく、生じるにつれて修復されるため、コンピュータユーザに対する妨げが少なくなることが含まれる。

［典型的なコンピューティング環境］
図１は、実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するのに適した典型的なコンピューティング環境を示す。１つの特定の構成を図１に示すが、そのようなコンピューティングデバイスは、他のコンピューティング構成においても実装することができる。

コンピューティング環境１００は、コンピュータ１０２の形態で汎用コンピューティングシステムを含む。コンピュータ１０２のコンポーネントには、１つまたは複数のプロセッサまたは処理装置１０４、システムメモリ１０６、ならびにプロセッサ１０４からシステムメモリ１０６までを含む様々なシステムコンポーネントを結合するシステムバス１０８が含まれることが可能であるが、以上には限定されない。

システムバス１０８は、様々なバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含め、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。システムバス１０８の例が、メザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスである。

コンピュータ１０２は、様々なコンピュータ可読媒体を含む。そのような媒体は、コンピュータ１０２がアクセスすることができる任意の利用可能媒体であることが可能であり、揮発性媒体と不揮発性媒体、リムーバブルな媒体とリムーバブルでない媒体がともに含まれる。システムメモリ１０６は、ランダムアクセスメモリ（ＲＡＭ）１１０のような揮発性メモリの形態、および／または読み取り専用メモリ（ＲＯＭ）１１２のような不揮発性メモリの形態でコンピュータ可読媒体を含む。スタートアップ中などにコンピュータ１０２内部の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（Basic Input/Output System）１１４が、ＲＯＭ１１２の中に格納される。ＲＡＭ１１０は、プロセッサ１０４が即時にアクセスすることができ、かつ／または現在、処理しているデータおよび／またはプログラムモジュール群を含む。

コンピュータ１０２は、他のリムーバブルな／リムーバブルでない、揮発性／不揮発性のコンピュータ記憶媒体も含むことが可能である。例として、図１は、リムーバブルでない不揮発性の磁気媒体（図示せず）に対して読み取りおよび書き込みを行うためのハードディスクドライブ１１６、リムーバブルな不揮発性の磁気ディスク１２０（例えば、「フロッピー（登録商標）ディスク」）に対して読み取りおよび書き込みを行うための磁気ディスクドライブ１１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などのリムーバブルな不揮発性の光ディスク１２４に対して読み取りおよび／または書き込みを行うための光ディスクドライブ１２２を示す。ハードディスクドライブ１１６、磁気ディスクドライブ１１８、および光ディスクドライブ１２２はそれぞれ、１つまたは複数のデータ媒体インタフェース１２５でシステムバス１０８に接続される。代替として、ハードディスクドライブ１１６、磁気ディスクドライブ１１８、および光ディスクドライブ１２２は、ＳＣＳＩ（small computer system interface）インタフェース（図示せず）でシステムバス１０８に接続することもできる。

ディスクドライブ群、および関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストレージをコンピュータ１０２に提供する。実施形態は、ハードディスク１１６、リムーバブルな磁気ディスク１２０、およびリムーバブルでない光ディスク１２４を示しているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）または他の光ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）などの、コンピュータがアクセス可能なデータを可能することができる他のタイプのコンピュータ可読媒体も、典型的なコンピューティングシステムおよびコンピューティング環境を実施するのに利用することができることを理解されたい。

例として、オペレーティングシステム１２６、１つまたは複数のアプリケーションプログラム１２８、他のプログラムモジュール群１３０、およびプログラムデータ１３２を含め、任意の数のプログラムモジュールが、ハードディスク１１６、磁気ディスク１２０、光ディスク１２４、ＲＯＭ１１２、および／またはＲＡＭ１１０に格納されることが可能である。そのようなオペレーティングシステム１２６、１つまたは複数のアプリケーションプログラム１２８、他のプログラムモジュール群１３０、およびプログラムデータ１３２のそれぞれ（または以上の何らかの組み合わせ）が、ユーザネットワークアクセス情報に関するキャッシュスキーム（ｃａｃｈｉｎｇ ｓｃｈｅｍｅ）を含むことが可能である。

コンピュータ１０２は、通信媒体として特定される様々なコンピュータ／プロセッサ可読媒体を含むことが可能である。通信媒体は、通常、搬送波などの変調されたデータ信号、またはその他のトランスポート機構でコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを実体化し、あらゆる情報配信媒体が含まれる。「変調されたデータ信号」という用語は、信号内に情報を符号化するような形で特性の１つまたは複数が設定された、または変更された信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響媒体、ＲＦ（radio frequency）媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。以上の媒体のいずれかの組み合わせも、コンピュータ可読媒体の範囲内に含まれる。

ユーザは、キーボード１３４やポインティングデバイス１３６（例えば、「マウス」）などの入力デバイス群を介して、コマンドおよび情報をコンピュータシステム１０２に入力することができる。その他の入力デバイス群１３８（特に図示せず）には、マイク、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、および／または同様のデバイスが含まれることが可能である。以上の入力デバイス群、およびその他の入力デバイス群は、システムバス１０８に結合された入出力インタフェース群１４０を介してプロセッサ１０４に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースおよびバス構造で接続してもよい。

モニタ１４２、または他のタイプのディスプレイデバイスも、ビデオアダプタ１４４のようなインタフェースを介してシステムバス１０８に接続することができる。モニタ１４２に加え、その他の出力周辺デバイス群には、入出力インタフェース群１４０を介してコンピュータ１０２に接続することができるスピーカ（図示せず）やプリンタ１４６などのコンポーネントが含まれることが可能である。

コンピュータ１０２は、リモートコンピューティングデバイス１４８のような、１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することができる。例として、リモートコンピューティングデバイス１４８は、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、またはその他の一般的なネットワークノードであることが可能である。リモートコンピューティングデバイス１４８は、コンピュータシステム１０２に関連して本明細書で説明した要素および機能の多く、またはすべてを含むことが可能なポータブルコンピュータとして例示されている。

コンピュータ１０２とリモートコンピュータ１４８の間の論理接続が、ローカルエリアネットワーク（ＬＡＮ）１５０および一般的なワイドエリアネットワーク（ＷＡＮ）１５２として表されている。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットで一般的である。ＬＡＮネットワーキング環境において実装される場合、コンピュータ１０２は、ネットワークインタフェースまたはネットワークアダプタ１５４を介してローカルネットワーク１５０に接続される。ＷＡＮネットワーキング環境において実装される場合、コンピュータ１０２は、通常、モデム１５６、または広域ネットワーク１５２を介して通信を確立するための他の手段を含む。コンピュータ１０２の内部にあることも、外部にあることも可能なモデム１５６は、入出力インタフェース群１４０、または他の適切な機構を介して、システムバス１０８に接続することができる。例示したネットワーク接続は、典型的であり、コンピュータ１０２および１４８の間で通信リンクを確立する他の手段も使用することができることを理解されたい。

コンピューティング環境１００で例示したようなネットワーク化された環境では、コンピュータ１０２に関連して示したプログラムモジュール群、またはプログラムモジュール群の諸部分は、リモートメモリ記憶装置の中に格納することができる。例として、リモートアプリケーションプログラム群１５８が、リモートコンピュータ１４８のメモリデバイス上に存在する。例示のため、オペレーティングシステムなどのアプリケーションプログラム群、およびその他の実行可能プログラムコンポーネントは、本明細書では、個別のブロックとして示しているが、そのようなプログラム群およびコンポーネントは、様々な時点で、コンピュータシステム１０２の異なる記憶コンポーネント内に存在し、コンピュータのデータプロセッサによって実行されることが認識されよう。

［典型的な実施形態］
図２は、実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するために構成されたコンピュータ１０２の典型的な実施形態を示す。コンピュータ１０２は、メモリ２０６の中に格納されたオペレーティングシステム２０２および様々なアプリケーションプログラム２０４を実行するように構成された１つまたは複数のプロセッサ２００を含む。本明細書で使用する「ボリューム」という用語は、一般に、データストレージの識別可能な単位を指すものとする。このため、ボリュームは、ハードディスク２１０などの物理的なストレージユニット上のいくつかの別々に識別可能なボリュームの１つであることが可能である。

ファイルシステムドライバ２０８（以降、ファイルシステム２０８と呼ぶ）も、コンピュータ１０２のメモリ２０６の中に格納される。一般に、ファイルシステム、またはファイル管理システムは、ディレクトリ群が、ディレクトリ群の下にファイルおよびサブディレクトリ群を有する階層システムなどの、コンピュータ１０２内部のボリューム２１０（例えば、ハードディスク）上にファイルを格納するための構造または規則である。このため、ファイル管理システムは、コンピュータ内部のハードディスク上にデータファイルが格納される仕方、どのようにファイルがボリュームから取り出されるか、ファイルに名前を付けるための規則などを規定する。「ファイルシステム」という用語は、しばしば、ファイル管理システムをサポートする、または管理するオペレーティングシステムのファイルシステムドライバ、ファイルシステムプログラム、またはファイルシステム部分を指すのに使用される。ファイルシステムドライバは、ディスク上のフォーマットを解釈して、ファイルシステム構造およびファイル規則を管理し、様々なユーザ／アプリケーション要求に応答して、ファイルを開くこと、ファイルを読み取ること、ファイルを書き込むこと、ファイルの名前を変更すること、およびファイルを閉じることなどのファイル操作を実行する。本明細書全体でメモリ２０６内に格納されたファイルシステムドライバ／コード２０８が説明されるのは、この状況においてである。つまり、ファイルシステム２０８は、前述したより一般的なファイル管理システムをサポートし、管理するオペレーティングシステムのプログラムまたは部分（すなわち、実行可能コード）を指すものとする。

したがって、ファイルシステム２０８は、コンピュータ１０２内部のハードディスク２１０の１つまたは複数のボリューム上にあるファイルの管理に関連する様々な操作を実行するように構成される。例えば、ファイルシステム２０８は、異なるユーザ／アプリケーション要求に応答して、ファイルを開くこと、ファイルを読み取ること、ファイルを書き込むこと、ファイルの名前を変更すること、およびファイルを閉じることなどのファイルトランザクションを実行する。ファイルシステム２０８は、通常、図２に示したオペレーティングシステム２０２と一体化される。ただし、ファイルシステム２０８は、オペレーティングシステム２０２と一体化した部分であることに限定されず、スタンドアロンのアプリケーションまたはプログラムモジュールであってもよい。さらに、メモリ２０６とハードディスク２１０を図２に別々に示しているが、メモリ２０６は、部分的に、または完全にハードディスク２１０の一部分であることも可能であることに留意されたい。ハードディスク２１０とメモリ２０６は、説明の目的でだけ、図２に別々に示している。このため、オペレーティングシステム２０２および様々なアプリケーションプログラム２０４が、メモリ２０６の中に格納されるように示しているが、オペレーティングシステム２０２およびアプリケーションプログラム群２０４は、ハードディスク２１０の１つまたは複数のボリューム上に格納されることも可能である。

本実施形態では、ファイルシステム２０８を、ワシントン州レッドモンド所在のＭｉｃｒｏｓｏｆｔ（登録商標）コーポレーションからの様々なウインドウ（登録商標）ブランドのオペレーティングシステムによって使用される、ＮＴＦＳ（Ｎｅｗ Ｔｅｃｈｎｏｌｏｇｙ Ｆｉｌｅ Ｓｙｓｔｅｍ）ファイルシステムであるものとして説明している。しかし、典型的なファイルシステムとしてのＮＴＦＳの使用は、説明するファイルシステム拡張機能を適用できる可能性がある他のファイルシステムおよびオペレーティングシステムに関する制限を意図するものではない。このため、本明細書で説明するリアルタイムなファイルシステム修復のためのファイルシステム拡張機能は、例えば、ＯＳ／２（商標）ベース、Ｍａｃｉｎｔｏｓｈ（商標）ベース、およびＵＮＩＸ（登録商標）ベースのオペレーティングシステム群などの、様々なオペレーティングシステムにおいて使用される、異なるファイルシステムに適用できる可能性がある。

前述したとおり、ファイルシステムトランザクションを管理することの１つの重要な態様は、ファイル管理システム内の内部整合性を維持することである。ディスク２１０のボリューム上のデータ破損は、ディスク２１０上の物理的な異常、コンピュータ１０２とハードディスク２１０の間における接続障害、あるいはデータが、メモリ内のランダムな場所に書き込まれることをもたらすオペレーティングシステムまたはドライバにおけるプログラミングバグなどの、様々な問題によって生じさせられる可能性がある。

リアルタイム修復モジュール２１２が、ファイルシステム２０８の一環として構成されて、コンピュータ１０２のファイル管理システムの整合性を維持するのを助ける。リアルタイム修復モジュール２１２は、一般に、ファイルシステム２０８によって検出された破損のリアルタイムなオンライン修復を可能にするように構成される。本明細書のこのセクションの残りの部分は、実行中のシステム内のボリューム上で検出された破損に応答する、ファイルシステム２０８と連携したリアルタイム修復モジュール２１２の動作を説明し、検出、修復プロセスのスケジュール、報告、および管理のための基本的な手続きの概要を述べる。それらのトピックのそれぞれのさらなる詳細は、付録と題する後のセクションで扱う。

リアルタイム修復モジュール２１２は、ファイルシステム２０８が破損ステータス指示／エラーを発生させた現在のコードポイントで応答するように構成される。その時点で、ファイルシステム２０８は、その特定の障害に関して修復手続きを開始するのに必要なだけ多くの情報を記録する。修復スキャンは、現行のスレッド内で最上の実行レベルに戻って実行されることが可能である。しかし、より複雑な修復スキャンは、専用のスレッドを要する可能性がある。

多くの修復は、実行中のシステム内でファイルを現在、操作しているすべてのユーザと両立し、このため、完全にトランスペアレントに修復されることが可能である。修復が、実行中のシステム内のファイルをユーザが操作していることと両立しない場合、ユーザは、修復に関連する副作用を経験する可能性がある。例えば、リアルタイム修復モジュール２１２は、ストリームをゼロの長さに切り捨てることを、そのストリームにアクセスする有効なハンドルが依然として存在しているのに行う可能性がある。そのようなファイルシステム修復は、書き込み側（ｗｒｉｔｅｒ）を共にするハンドルに関しては適合するが、それ以外では不適合である。不適合なハンドルは、無効にされなければならず、不適合なハンドルに対する将来の操作は、失敗する。

何らかの形態の破損に起因して完了させることができないファイルシステム２０８に対する最上レベルの要求は、エラーステータスで拒否されること、または短期修復が完了するまでブロックされることが可能である。現行のファイルシステム要求に関して検出される破損は、現行の要求自体の中で最初に検出されることも、以前の要求に関連するより早期の検出の結果として既に検出済みであり、修復されている最中であることも可能である。いずれに関しても、行われるべき適切な修正アクションを示す修復の複雑さのレベルが定義される。

ファイルシステム２０８および修復モジュール２１２は、破損検出に応答してスケジュールされた修復処理を優先させる。これは、コンポーネント間の依存関係を少なくすることにより、将来の機構を設計することを簡単にする。

破損を検出する際、ファイルシステム２０８は、ハードディスク２１０からメタデータが読み取られ、処理されるにつれ、メタデータを検証する。ファイルシステム２０８は、メタデータ破損を直接に検出し、各破損を示すエラーステータスを発生させる。破損が検出された時点で、ファイルシステム２０８および修復モジュール２１２は、必要とされる修復の範囲を特定し、その範囲を現行のスレッド内で最上レベルのファイルシステムコンテキスト構造の中に記録する。通常、ファイルシステム２０８は、破損を有するメタデータストリームに対するロックを既に保持しており、関係のあるデータ構造上に必要な状態情報を設定して、それらのデータ構造が、無効な状態にある、または修復中であると示すことができる。これは、修復モジュール２１２が、それらの同一のファイルに対する未処理の要求、および将来の要求と修復処理を同期させることを可能にする。

ファイルシステム２０８および修復モジュール２１２は、他のコンポーネントにおける障害に起因する破損も扱う。そのような破損の２つの主な原因は、ログファイルにおけるデータ損失、および失敗したファイルシステムトランザクション中止である。ログファイル障害は、通常、ボリューム再起動時に生じる。破損ステータスが発生させられ、ファイルシステム２０８が、ボリューム（例えば、ディスク２１０）をマウントすることに失敗する。修復モジュール２１２は、このエラーを捕らえ、ログファイルの再初期化を生じさせる。ファイルシステム２０８は、その時点で、可能なボリューム破損を無視し、実行中のシステム内の破損を検出する通常の機構に依存することを選択することが可能である。

リアルタイム修復モジュール２１２は、検出された破損のリストを処理する単一のルーチンを介して修復を実行し、修復の完了を待っているファイルシステムユーザ要求のリストを有する。複雑な修復スキャンは、修復処理を行うのに専用のスレッドを要する可能性がある。専用のスレッドは、必要に応じてだけ生成され、同一の共通修復ルーチンを呼び出す。小規模の修復ルーチンが、スタックにおける最上レベルの実行ポイントで、インラインで実行される。小規模の修復ルーチンは、長さ１の修復キュー（ｑｕｅｕｅ）、および長さ１の保留中ＩＲＰキューを扱う。これは、複数の修復が並列に行われることを可能にする。それらのローカル修復処理の１つが、連鎖的な（ｃａｓｃａｄｉｎｇ）破損、またはより複雑な破損に出会った場合、ローカル作業キューおよびＩＲＰキューをグローバル作業キューに移動させることができる。これにより、他のローカル修復処理が中止され、グローバル作業キューに移されることも生じさせられることが可能である。

破損は、再帰的なファイルシステム要求内で検出されることも可能である。その場合、ファイルシステム２０８は、修復を実行するために最上レベルの要求まで戻る（ｕｎｗｉｎｄ）。これにより、修復が実行されている最中に、ファイルシステム２０８の中に呼び出し元によって保持されるリソースがまったく存在しないことが確実にされる。ファイルシステム２０８は、リソースがまったく保持されていない最上レベルに戻ることができない場合、修復を作業キューにポスティングし（ｐｏｓｔ）、現行のスレッド内の要求を拒否する。いずれにしても、再帰的なファイルシステム要求のすべてが、破損ステータスエラーで拒否されることが必要である。これは、異なる要求のコンテキスト内で要求を開始することができるファイルシステムフィルタ群に影響を与える可能性がある。

一部のケースでは、ファイルシステム２０８は、壊れたブートセクタまたはＭＦＴ（マスタファイルテーブル）ファイル内の切断（ｄｉｓｃｏｎｎｅｃｔ）に起因して、ボリューム（例えば、ディスク２１０）をマウントすることができない。壊れたブートセクタが存在する場合、いずれのファイルシステムが実際にそのボリュームを「所有する」かについて確かではない。このため、ファイルシステム２０８は、ディスク２１０をスキャンしてメタデータを再構築し、ブートセクタを修復する一方的なアクションを行うことができない。これは、ボリューム上に残余のファイルシステムメタデータが存在する可能性があるが、ボリュームが、異なるファイルシステムにクイックフォーマット（ｑｕｉｃｋ ｆｏｒｍａｔ）されている可能性があるためである。それらの状況下では、ボリュームが、ＮＴＦＳボリュームなどの特定のファイルシステムボリュームとして扱われることを強制することができるオフラインツールが、管理者によって実行される必要がある。そのようなオフラインツールは、ボリュームをスキャンして、ブートセクタを再構築することができる。ブートセクタが整えられると、ファイルシステム２０８は、独自のボリュームスキャンを行ってファイルシステムメタデータの残りの部分を再構築することができる。このフル（ｆｕｌｌ）スキャンは、壊れたブートセクタ問題の修復プロセスを完了させ、ＭＦＴファイル内の切断の問題も処理する。

ファイルシステム２０８は（リアルタイム修復モジュール２１２と連携して）、ファイルシステム２０８が破損を検出した時点で見られた破損の性質を記述する重要な情報を記録する。ファイルシステム２０８および修復モジュール２１２は、検出された破損のタイプに対応する一連の修復スキャンを定義する。破損検出の時点で、定義された修復スキャンに対応する作業項目が生成される。一部の複合修復スキャンは、より低いレベルのスキャンの集合に追加の検査を加えたものである。より低いレベルのスキャンの集合である複合修復スキャンを完了させることにより、より低いレベルのスキャンの正しさが保証される（ファイル検査を行うことにより、属性が正しいことが保証される）。他の修復スキャンは、現在、実行中のスキャンが、正常に実行されることが可能であるには、他のファイルシステムメタデータの正しさに依存する可能性がある（例えば、ディレクトリの再構築が、そのディレクトリに含まれるファイルのファイル名検査をブロックする可能性がある）という点で、階層型である。

ファイルシステム２０８は、破損検出中に生成された作業項目間の関係、ならびに現在、進行中の修復、および保留中の修復を保持する。より複雑なスキャンの中に含まれる修復スキャンは、より複雑なスキャンに組み込まれる（ｆｏｌｄｅｄ ｉｎｔｏ）。複雑なスキャンが完了すると、コンポーネントスキャンのそれぞれが完了されたものと考えられる。階層型修復スキャンは、それらのスキャンが依存するスキャンが完了した時点で引き起こされる（triggered）。それらの関係を維持するため、ファイルシステム２０８は、より高い優先順位のスキャンを上で実行するために、進行中の修復スキャンを中止することをサポートする。

修復スキャンのいくつかの例には、以下が含まれる。すなわち、
・属性スキャン
・ファイルスキャン
・インデックススキャン
・ボリュームビットマップ再構築
・セキュリティ記述子ファイルスキャン
リアルタイム修復モジュール２１２を有するファイルシステム２０８は、修復スキャンを実行している最中にさらなる破損が見つかったケースにも対処する。クリーンなアーキテクチャモデルを維持するため、現行の修復スキャンと見つかった破損のタイプの間の関係が、前述した関連する修復スキャンの２つのタイプのどちらかに適合させられる。現行の修復スキャンは、包含するメタデータオブジェクトの修復に組み込まれる（すなわち、属性を修復している最中にさらなるファイル破損が検出される）か、または新たな修復スキャンが完了するまで延期される（すなわち、ディレクトリ内のファイルのファイルレコードが修復されるまで、ディレクトリ検証が延期される）。これは、修復を行っている最中に見つかる可能なあらゆる破損が、最初の修復にまったく依存することなしに、スケジュールされ、修正されるように、個々の作業項目の注意深い定義を要する。

リアルタイム修復モジュール２１２を有するファイルシステム２０８は、実行中のシステムに最小限の影響しか与えずに修復を実行し、修復中に行われた変更の性質に関して完全な報告を提供する。ただし、クライアントアプリケーション群２０４は、修復の深刻さ、およびオープンハンドルのモードに依存して、ファイルシステム破損の修復に起因して影響を受ける可能性がある。修復が迅速である場合、アプリケーションによって生成されるあらゆる最上レベルのＩＲＰは、修復が行われている間、待たされる。そのようなケースでは、修復処理は、アプリケーション２０４にトランスペアレントでなければならない。しかし、修復が些細ではない場合、ファイルシステム２０８に対するアプリケーション要求は、破損ステータスエラーで拒否される可能性がある。

アプリケーション２０４は、アプリケーション２０４を構成する実行可能ファイル、ならびに使用中のあらゆるデータファイルに対する修復を含め、修復処理の結果を管理する必要がある。可能な場合、ファイルシステム２０８は、ＵＳＮイベントおよび通知イベントを介して変更を報告する。変更が、ファイルの現在のアクセスおよび共有モードと両立する場合、アプリケーション２０４は、問題なく続けられることが可能であるはずである。しかし、修復がアプリケーション２０４と両立しない場合、アプリケーション２０４は、無効ハンドルステータスエラーを受け取る。アプリケーション２０４は、アプリケーションのハンドルが、ファイルにアクセスするのにもはや使用することができないケースを扱う必要がある。一般に、ファイルシステム２０８および修復モジュール２１２、ファイルは、マウントの解除および修復なしにアクセス可能にすることができる。

ファイルシステム２０８は、現在、修復されている、または修復のためにキューに入れられているすべての破損をディスク上に記録しようとはしない。ファイルシステム２０８は、実行中のシステム内で破損を再び見つけ、修復するはずなので、すべての破損が保存されることを保証しなければならない複雑なディスク上の表現を展開することに、ほとんど利点はない。しかし、長期実行（ｌｏｎｇ−ｒｕｎｎｉｎｇ）スキャンが進行中であること、および実行中のシステム内における最新の到達点を記録することには、利点がある。ファイルシステム２０８は、その情報をディスク２１０上でボリュームファイルレコードの中に入れることができる。しかし、このデータ自体も、破損を受けるので、このデータがディスク上で正しいことを保証することは不可能である。ファイルシステム２０８は、実行中のシステム内のボリュームファイルレコードを修復している最中であることも可能であり、したがって、その時点でその記録を書き込むことができない可能性がある。

ファイルシステム２０８は、ステータスファイル破損エラーコードおよびステータスディスク破損エラーコードを使用して、何らかの破損関連のエラーのために現在の動作に障害が生じている場合、それを示す。これらのステータスコードで障害が生じる可能性がある、以下の３つのクラスの障害が存在する。すなわち、
・動作を実行している最中に見つかった破損−些細でない修復が要求される
・ユーザ操作が、長期実行修復が完了することを要する
・修復作業に起因してハンドルが、現在、無効である−ファイルシステムが、共有モード、所望されるアクセス、保持されるファイルロック、またはファイルに対して保持されるｏｐｌｏｃｋと両立しない何らかの形でファイルを修復した。

ファイルシステム２０８は、許可されたユーザが修復プロセスと対話することができるようにする機能も提供する。システム管理者が、ファイルシステムメタデータに対して検証スキャンを開始することができる。ファイルシステム２０８は、管理者が、検証の範囲を指定することができるように柔軟性を提供する。これには、以下が含まれることが可能である。すなわち、
・完全なボリュームスキャン
・セキュリティスキャン
・ファイルスキャン
・ストリームスキャン
・ディレクトリスキャン
・ビューインデックススキャン
ファイルシステム２０８は、現行の修復処理および進行ステータスを報告する機構も提供する。些細な修復処理についてまったく情報を報告する必要はない。というのは、ユーザは、破損が存在するという理由でファイルシステム要求が拒否されることを決して経験しないはずだからである。ただし、些細な修復がオープンハンドルを無効にする可能性があることに留意されたい。

ファイルシステム２０８は、修復処理の背後でブロックすることができる通知機構も提供する。システム管理者は、ボリュームハンドルを使用して、進行中の複雑な修復上または検証スキャンを待つことができる。これがうまくいくようにするために、ファイルシステム２０８は、破損に起因してボリュームオープンを却下する（ｆａｉｌ）ことをしない。そのハンドル上でステータス破損エラーを受け取ったユーザは、そのハンドルを使用して、そのハンドル上で修復が完了するのを待つことができる。

ボリュームのマウントの解除は、修復が進行中である場合、大幅にブロックされない。あらゆる短期修復が、完了されることが可能である。長期実行スキャンが、ユーザによって再び開始される必要がある可能性がある。修復キューに入っている他の些細なエラーの修復は、それらのエラーが次のボリュームマウント中に検出されるので、キャンセルされ、再試行される。

リアルタイム修復モジュール２１２を有するファイルシステム２０８は、入出力、ＣＰＵ（central processing unit）、またはメモリを集中的に使用する可能性がある。というのは、ファイルシステム２０８は、ボリューム全体をスキャンして、修復処理を実行するからである。このオーバーヘッドは、一部のクリティカルな環境では許容できない可能性がある。そのようなケースでは、ファイルシステム２０８は、長期実行スキャンに関して自動修復を無効にする方法を提供し、管理者がスキャンを直接に開始することを要求する。一方的な短命の修復処理は、依然、ファイルシステム２０８によって開始される。

リアルタイム修復モジュール２１２を有するファイルシステム２０８は、修復を実行している最中に繰り返されるハードウェアエラーまたは断続的なハードウェアエラーを見つける可能性がある。断続的なエラーは、修復を不可能にする可能性がある。その場合、ファイルシステム２０８（修復モジュール２１２）は、修復を行うことができず、ボリュームを壊れた状態のままにする。可能な場合、ファイルシステム２０８は、ユーザがハードウェア問題に対処すべきであるという意図で、そのことをイベントログの中に記録する。繰り返し可能なエラーの場合、ファイルシステム２０８は、そのクラスタを不良クラスタファイルに回収し、そのデータを失われたものとして扱う。

リアルタイム修復モジュール２１２を有するファイルシステム２０８は、実行中のシステムの状態に起因するエラーを見つける可能性もある。エラーの主な源は、何らかの動作を実行するのにプールメモリが不十分であることである。その場合、ファイルシステム２０８は、可能な場合、その障害をイベントログの中に記録し、修復を終了させる。修復は、破損が再び見つかる、将来の何らかの時点で再び試みられる。

［典型的な方法］
次に、実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するための典型的な方法を、図３〜５の流れ図を主に参照して説明する。その方法は、一般に、図１および図２に関連して前述した典型的な実施形態に適用される。１つまたは複数の方法を、流れ図、ならびに流れ図のブロックに関連する本文で開示するが、説明する方法の要素は、必ずしも、それらの要素が提示される順序で実行される必要はなく、代替の順序も同様の利点をもたらすことが可能であることを理解されたい。さらに、方法は、排他的ではなく、単独で、または互いに組み合わせで実行されることが可能である。説明する方法の要素は、例えば、ＡＳＩＣ（application specific integrated circuits）上のハードウェア論理ブロックによって、またはプロセッサ可読媒体上で定義されたプロセッサ可読命令の実行によって実行されることを含め、任意の適切な手段によって実行されることが可能である。

本明細書で使用する「プロセッサ可読媒体」は、プロセッサによって使用される、または実行される命令を含む、格納する、通信する、伝搬する、またはトランスポートすることができる任意の手段であることが可能である。プロセッサ可読媒体は、限定としてではなく、電子、磁気、光学、電磁、赤外線、または半導体のシステム、装置、デバイス、または伝搬媒体であることが可能である。プロセッサ可読媒体のより具体的な例には、とりわけ、１つまたは複数の線を有する電気接続（電子）、ポータブルコンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、読み取り専用メモリ（ＲＯＭ）（磁気）、消去可能なプログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ（光学）、書き換え可能ＣＤ（ＣＤ−ＲＷ）（光学）、およびポータブルＣＤ−ＲＯＭ（ｃｏｐｍａｃｔ ｄｉｓｃ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）（光学）が含まれる。

方法３００のブロック３０２で、ストレージボリューム上のデータに関して破損が検出される。ファイルシステム２０８が、破損を検出する。破損は、現行のファイルシステム要求中に、またはその要求に関連して検出されることも、以前のファイルシステム要求中に検出済みであることも可能である。ファイルシステム２０８は、ブロック３０４で示すとおり、破損が検出された時点で、その破損を記述する情報を記録する。ブロック３０６で、ファイルシステムは、破損が検出されたことを示すエラーステータスを生じさせる。ブロック３０８で、ファイルシステムは、オプションとして、破損の存在を示すエラーステータスに応答して、現行のファイルシステム要求の実行を中断する。

ファイルシステムは、ブロック３０８で記録された情報を使用して、検出された破損に基づいて修復スキャンを定義する。典型的な修復スキャンには、属性スキャン、ファイルスキャン、インデックススキャン、ボリュームビットマップ再構成、およびセキュリティ記述子ファイルスキャンが含まれる。修復スキャンを定義することには、より低いレベルのスキャンの集合を含む複合修復スキャンを定義することが含まれることが可能である。

ブロック３１２で、修復スキャンが、ファイルシステム（例えば、図２のリアルタイム修復モジュール２１２）によって実施される。修復スキャンを実施するように修復ルーチンが実行される。修復ルーチンは、現行のスレッド内における最上レベルの実行ポイントで実行されることが可能であり、あるいは修復スキャンを行う別個の／専用のスレッドが開始されることも可能である（すなわち、修復が、キューの中に入れられ、このキューにおいて専用のスレッドがその修復を受け取り、実行する）。修復スキャンが、複合修復スキャン（すなわち、より低いレベルのスキャンの集合を含む）である場合、あらゆる関連するより低いレベルのスキャンを含む複合修復スキャンが実施される。ファイルシステム要求が、再帰的な要求である場合、ファイルシステムは、再帰的な要求における最上レベルの要求まで戻り、その最上レベルの要求に関して修復スキャンを実施する。

方法３００は、ブロック３１４で図３から図４に続く。ブロック３１４で、現行のファイルシステム要求が、修復スキャンが完了した後に実行を再開する。ファイルシステム要求を再開することには、通常、意図されるとおり要求を完了させることが含まれる。しかし、修復スキャンが些細ではない修復スキャンであり、そのため、まだ完了していない場合、ファイルシステム要求は、拒否され、ファイルシステムは、破損ステータスエラーを発行する。同期要求は、修復が完了するまで待ってから、再開されることが可能である。また、修復スキャンが、アプリケーションのアクセスハンドルが要求を行うことと両立しない場合、要求は、拒否され、ファイルシステムは、無効ハンドルステータスエラーを発行する。

ブロック３１６で、現行の修復スキャンを受けるファイルに関連する第２のファイルシステム要求が、受け取られる。現行の修復スキャンが長期実行修復スキャンである場合、第２のファイルシステム要求は、ブロック３１８で示すとおり、拒否される。現行の修復スキャンが短期実行修復スキャンである場合、第２のファイルシステム要求は、ブロック３２０で示すとおり、現行の修復スキャンが完了するまでブロックされる。

ブロック３２２で、現行の修復スキャンを無効にする（ｄｉｓａｂｌｅ）ファイルシステム制御（ｆｓｃｔｌ）コマンド（すなわち、通知機構）が、受け取られる。そのようなｆｓｃｔｌコマンドは、ユーザ／管理者入力から受け取られる。現行の修復スキャンが長期実行修復スキャンである場合、修復スキャンは、ブロック３２４で示すとおり、無効にされる。そうではない場合、現行の修復スキャンは、完了される。

ブロック３２６で、修復スキャンを実施している最中にさらなる破損が検出される。その場合、修復スキャンは、ブロック３２８で示すとおり、新たな修復スキャンが完了するまで、延期されることが可能である。

ブロック３３０で、修復スキャンを実施している最中に断続的なハードウェアエラーが検出される。修復スキャンは、ブロック３３２で示すとおり、断続的なハードウェアエラーが検出された場合、拒否される。断続的なハードウェアエラーに起因して拒否された修復スキャンは、ブロック３３４で示すとおり、イベントログに記録される。その後、ユーザが、ログを調べ、ハードウェアエラーを修正することができる。

ブロック３３６で、修復スキャン中にファイルシステムデータに対して検証スキャンが開始される。典型的な検証スキャンには、完全なボリュームスキャン、セキュリティスキャン、ファイルスキャン、ストリームスキャン、ディレクトリスキャン、およびビューインデックススキャンが含まれる。

［付録］
この付録は、ファイルシステム２０８およびリアルタイム修復モジュール２１２に関連して前述した、破損検出、修復スケジュール、破損および修復の報告、および修復プロセスを管理することのさらなる詳細を提示する。前述したとおり、ＮＴＦＳ（Ｎｅｗ Ｔｅｃｈｎｏｌｏｇｙ Ｆｉｌｅ Ｓｙｓｔｅｍ）ファイルシステムを典型的なファイルシステムとして提示するが、説明するファイルシステム拡張機能の適用をいずれかの特定のファイルシステムに限定する意図はまったくない。

アプリケーションの適合性
クライアントアプリケーションは、修復の深刻さ、およびオープンハンドルのモードに依存して、ＮＴＦＳ破損の修復に起因して影響を受ける可能性がある。修復が迅速である場合、アプリケーションによって生成されるあらゆるファイルシステム要求は、修復が行われている間、待たされる。そのようなケースでは、修復処理は、アプリケーションにトランスペアレントでなければならない。しかし、修復が些細ではない場合、要求は、ＳＴＡＴＵＳ−ＣＯＲＲＵＰＴ−ＸＸＸクラスのエラーで失敗する。

アプリケーションは、無効にされたハンドル、またはアプリケーションが操作している、基礎にあるファイルの変更を含むことが可能な修復処理の結果を扱う必要がある可能性がある。修復は、アプリケーションを構成する実行可能ファイル、ならびに使用中のあらゆるデータファイルに影響を与える可能性がある。可能な場合、ＮＴＦＳは、ＵＳＮイベントおよびＤｉｒＮｏｔｉｆｉｃａｔｉｏｎイベントを介して変更を報告する。変更が、ファイルの現在のアクセスおよび共有モードと両立する場合、アプリケーションは、問題なく続けられることが可能であるはずである。しかし、修復がアプリケーションと両立しない場合、アプリケーションは、ＳＴＡＴＵＳ−ＩＮＶＡＬＩＤ−ＨＡＮＤＬＥを見る。アプリケーションは、アプリケーションのハンドルが、ファイルにアクセスするのにもはや使用することができないケースを扱う必要がある。これは、破損により、ファイルにアクセスできなくなる可能性があるが、自己回復（ｓｅｌｆ−ｈｅａｌｉｎｇ）ＮＴＦＳを使用して、マウントの解除および修復なしに、ファイルをアクセス可能にすることができる現行の挙動に類似する。

複数のデータファイルを使用し、データファイルにわたるデータ整合性に依存する、うまく書かれたアプリケーションは、アプリケーションがファイルにアクセスするのに使用するハンドルの無効化が伴うファイルの１つまたは複数に対する変更によって影響を受ける。これは、ＡｕｔｏｃｈｋまたはＣｈｋｄｓｋが、ボリュームマウントとボリュームマウントの合間にデータファイルの１つを変更する可能性がある現行のモデルに似通って見える。

実行可能ファイルが修復され、ファイルの中のデータが変更されている可能性がある。ＮＴＦＳは、イメージとして現在、マップされているストリームを、ＮＴＦＳがそのストリーム内のバイトに影響を与える変更を行った場合、無効にする必要がある。実行中のイメージは、そのイメージが依然としてメモリ内にある限り、まったくエラーに遭遇しない可能性がある。いずれの要求も、無効というマークが付けられたファイルハンドルまたはストリームでＮＴＦＳに達した時点で、ＮＴＦＳは、ＳＴＡＴＵＳ−ＩＮＶＡＬＩＤ−ＨＡＮＤＬＥで現行の要求を拒否する。一部のファイルに対して行われた修復により、アプリケーション、またはオペレーティングシステムさえ死ぬ可能性がある。

同時実行のファイルアクセス
自己回復ＮＴＦＳは、開かれている、または作成されているファイルが、現在、実行中の修復処理、またはスケジュールされている修復処理に起因して、変更または削除を受けるかどうかをチェックしなければならない。この修復は、通常、ファイル自体に対して実行されるが、親に対するディレクトリスキャン、またはセキュリティファイルの再構築などの、目標ファイルに影響を与える他のケースも存在する。そのファイルに影響を与える可能性がある何らかの修復が実行されている場合、読み取り側（ｒｅａｄｅｒｓ）、書き込み側（ｗｒｉｔｅｒｓ）、および削除側（ｄｅｌｅｔｅｒｓ）を同じくする共有モードでのオープンだけが成功する。不適合なオープンは、進行中の修復の複雑さに依存して、ブロックされるか、または失敗する。一実施形態では、すべてのユーザファイルオープンは、修復の進行中、ブロックされる。

新規ファイル作成
新規ファイル作成は、呼び出し側が全員と共有するのを厭わないという条件付きで、以下の修復の際にブロックされる。それ以外の場合、新規ファイル作成は、適切なエラーで失敗する。

目標作成の祖先に対するディレクトリスキャン。これには、新規のファイルを作成する最中に辿られる（ｔｒａｖｅｒｓｅｄ）あらゆるディレクトリが含まれる。

セキュリティストリームに対する修復。

既存のファイルのオープン
既存のファイルのオープンは、呼び出し側が全員と共有することを厭わないという条件付きで、以下の修復の際にブロックされる。既存のファイルのオープンは、それ以外の場合、適切なエラーで失敗する。

開かれているファイルに対するあらゆるスキャン
そのファイルをオープンにするために辿られた親に対するディレクトリスキャン。

既存のオープンハンドル
自己回復ＮＴＦＳは、修復を実行することに常に優先権を有する。これは、修復に、読み取りアクセス、書き込みアクセス、および削除アクセスが常に認められることを意味する。このアクセスが認められると、このアクセスと両立しないあらゆる既存のハンドルが、無効にされなければならない。ＮＴＦＳは、ファイルに関するＣＣＢに無効というマークを付け、要求を拒否する。一部のケースでは、ストリーム上のすべての既存のハンドルが無効にされなければならない。それらのケースでは、ＮＴＦＳは、ファイルをバックする（ｂａｃｋ）ＳＣＢを孤立させ（ｏｒｐｈａｎ）、ストリームに対する将来のアクセスのために新規のＳＣＢを作成する。

マップされたファイル
マップされたファイルの現行のＮＴインプリメンテーションは、ユーザがマップしたアクティブなセクションが存在する場合、ファイルが切り捨てられることを防止する。ユーザは、そのセクションを介してファイルデータに対する直接アクセスを有し、ＮＴＦＳは、そのアクセスをシリアル化する手段を有さない。自己回復ＮＴＦＳは、マップされたセクションでストリーム内のデータを変更する理由をまったく有さないが、ストリームを切り捨てる、または削除さえする必要がある可能性がある。マップされたセクションと両立しないのは、修復切り捨て動作である。ＮＴＦＳは、その場合、データセクションを孤立させる必要があり、これは、そのセクションを使用するすべてのオブジェクトを意味する。キャッシュマネージャもそのセクションを使用する。現在、そのストリームに対するすべてのハンドルおよびセクションが、無効にされる必要があり、それらのハンドル上のいずれのアクセスも、ＳＴＡＴＵＳ＿ＩＮＶＡＬＩＤ＿ＨＡＮＤＬＥを戻す。

単純な例−ユーザが、そのハンドルを使用してファイルをマップしたらどうなるか。マップするコールを調べ、そのコールが、ファイルシステムコールバックにおいて失敗する可能性があるかどうかを確かめる。

イベントログ記録
ＮＴＦＳ修復スレッドによって行われたすべての破損検出および後の修復が、システムイベントログおよび／または修復ログに記録される。すべてのイベントログエントリは、以下のデータの一部、またはすべてを含む。すなわち、
・修復の説明的理由
・ファイル名、およびファイルへの完全なパス
・破損に関するＶＣＮ（割り当て破損に関する）
・ファイルＩｄ
イベントログおよび／または修復ログ自体、壊れている可能性があることに留意されたい。

孤立したクラスタの保存
孤立したクラスタの保存は行われない。孤立したクラスタは、ビットマップにおいて割り当て済みというマークが付けられているが、いずれのファイルにも属さないクラスタである。

孤立したファイルの保存
Ｃｈｋｄｓｋの挙動と同一の処理が行われる。

マップされたファイルおよびイメージ
メモリマネージャは、データセクションまたはイメージセクションをバックする（ｂａｃｋ）ファイルが切り捨てられることを許さない。修復が、マップされたセクション、またはイメージセクションをバックするストリームを切り捨てる、または削除することを必要とする場合、ＮＴＦＳは、その属性を無効にする。バッキング（ｂａｃｋｉｎｇ）属性を読み取ろうとする、またはバッキング属性に書き込もうとするあらゆる試みは、ＳＴＡＴＵＳ＿ＩＮＶＡＬＩＤ＿ＨＡＮＤＬＥで失敗する。このエラーは、データが既にメモリ内にある状態でアプリケーションが実行され続けるので、即時に現れない可能性がある。ＮＴＦＳは、実際の属性を無効にしなければならないので、属性に対するハンドルが、修復処理と両立するハンドルでも、無効にされることを意味する。

Ｏｐｌｏｃｋ
Ｏｐｌｏｃｋは、呼び出し側が、ファイルを別の場所にローカルでキャッシュしている可能性があることを示唆する。Ｏｐｌｏｃｋが解除された時点でＮＴＦＳストアに書き込まれる（ｗｒｉｔｔｅｎ ｂａｃｋ）保留中の変更が、その場所に存在する可能性がある。自己回復ＮＴＦＳはまず、いずれのハンドルが無効である可能性があるかを判定して、修復中に不適合な動作が行われるのを防止する。次に、ＮＴＦＳは、Ｏｐｌｏｃｋを解除し、修復を開始する。ＮＴＦＳは、Ｏｐｌｏｃｋ解除確認を待ってから、修復を開始する。これは、修復モデルを簡単にするためであり、修復が開始されることが可能になる前に、ユーザアクションを待つシステムをブロックするためではない。

排他的Ｏｐｌｏｃｋは、常にＦＩＬＥ＿ＯＰＬＯＣＫ＿ＢＲＯＫＥＮ＿ＴＯ＿ＮＯＮＥに解除される。ＮＴＦＳは、Ｏｐｌｏｃｋを保持しているハンドルが、ハンドルの適合性をチェックするより早期のスキャンが成功する限り、書き込み動作を実行することを許す。ファイルロック解除（Ｂｒｅａｋ ｆｉｌｅ ｌｏｃｋｓ）により、様々なファイルが保護される。ファイルシステムフィルタ群は、最上レベルでだけ修復される。ユーザがハンドルを有する場合、フィルタが、異なるファイルへのアクセスを常にマップすることが可能である。これは、ユーザのファイルが修復中である場合、おそらく問題ではない。これを入出力レベルで拒否する（ｆａｉｌ）ようにする必要はない。

特別ファイル
ハイバーファイル（ｈｉｂｅｒｆｉｌｅ）、ページファイル（ｐａｇｅｆｉｌｅ）、レジストリハイブ（registry hive）、ＴｘＦ ＴＯＰストリーム、およびクラッシュダンプ（ｃｒａｓｈｄｕｍｐ）のような特別ファイルは、修復するのに固有の問題を有する。これらのファイルは、ファイルシステムに密接に結びついており、これらのファイルの読み取り側および書き込み側は、これらのファイルのクラスタレイアウトについて仮定している。それらのアプリケーションのユーザが、アプリケーションのファイルにもはや属さない可能性があるクラスタを使用し続け、ディスクを壊すのを止めさせる通知機構が提供される。

同じことが、ＭＡＲＫ＿ＨＡＮＤＬＥで留められた（ｐｉｎｎｅｄ ｂｙ）ファイルについても言える。それらのファイルは、必ずしもハンドルオープンを有さずに（それらのファイルは、ファイルを参照するファイルオブジェクトを有するか）クラスタに対して直接のＩ／Ｏを実行するので、扱うのが特に困難である。それらのファイルを修復しないことは、妥当な妥協案である。ページファイル内の破損は、許容できない可能性がある。ページプール（ｐａｇｅｄ ｐｏｏｌ）問題に対処しなければならない。さらに悪くすると、我々の独自のコードが、ページインされる（ｐａｇｅｄ ｉｎ）必要がある可能性がある。

トランザクション（Ｔｒａｎｓａｃｔｅｄ）ＮＴＦＳ（ＴｘＦ）
目標ファイルが、ＴｘＦトランザクションの一部分である場合、修復は、実際に変更を行う前に、ＴｘＦに通知する必要がある。これは、ファイルハンドルが無効にされるのとほぼ同時にリソースが保持されて行われる同期コールアウト（ｃａｌｌ ｏｕｔ）である。（実際、ＴｘＦは、自らすべてのハンドル無効化を行うことができる。）ＴｘＦの方は、ＴｘＦファイルロックを除き、トランザクション（バージョン履歴、ＳＴＯＰＳストリームなど）のためにメモリ状態にあるＴｘＦのすべての、を解放する。修復は、修復が終了するとやはりＴｘＦにコールアウトを行い、必要な場合、ＴｘＦがトランザクション中止を行うことができるようにする。懸念されるのが、これらのコールアウトの細分性である。コールアウトが、修復に負担になりすぎてはならない。すべての既存のトランザクションを中止することが、ボリューム全体にわたる特に破壊的な修復に関して、実行できる問題解決法である可能性がある。

ＴｘＦは、ファイルが、特にクラッシュ後、または中止の間、ＴｘＦが要求する状態になっていないというより一般的な問題に対処する必要もある。ＴｘＦは、修復がＴｘＦの動作を妨げる場合はいつでも、それをイベントログに書き込む。修復が、トランザクションの完全性に対して破壊的である場合、トランザクションは中止される。これは、トランザクション（ｔｒａｎｓａｃｔｅｄ）動作の持続性を確実にするためであり、特定の変更が、何らかの理由で達せられなかった場合、それをユーザが知ることを可能にする。すべての既存のトランザクションハンドルは、無効にされる。

ＴＯＰＳストリームもＣｏｍｍｏｎ Ｌｏｇファイルも、修復されることが可能な特別ファイルとして扱われる。しかし、ＴｘＦおよびＣｏｍｍｏｎ Ｌｏｇは、それぞれの領域内の破損にどのように対処すべきかを知る必要がある。しかし、それらの破損が修復されることが許されれば理想的である。というのは、そうでなければ、それらの破損は、単に壊れたままにされるからである。

マウント中に検出された壊れた初期システムファイルレコード
ボリュームが、有効なバージョンを有するＮＴＦＳボリュームとして認識されると、ファイルシステムは、初期システムファイルレコードのそれぞれを検証する。この内部ファイル検証は、破損が検出された場合、完全なボリュームスキャンに容易に拡張されることが可能である。

ＮＴＦＳ再起動失敗
ＮＴＦＳは、再起動を実行している最中にＬＯＧ＿ＦＩＬＥ＿ＦＵＬＬに行き当たる可能性がある。理論上、これは、予約戦略が正しい場合、不可能である。これは、マウントを再試行するが、再起動を実行しないことによって対処される。これは、ＮＴＦＳが、背景でフルスキャンを実行することを要求するが、その間、ボリュームは、利用可能でなければならない。

属性
属性は、低レベルの動作を記述し、特に、ディスクに対してどのようなアクションが行われるかを記述する。

基本属性
基本属性は、ファイルレコード内の属性である。基本属性は、常駐（ｒｅｓｉｄｅｎｔ）属性、ＶＣＮ０における非常駐属性、または１つの非常駐ストリームを記述する任意の属性であることが可能である。

ディスク上の内部属性の矛盾−ＶＣＮ０におけるユーザデータ属性を除き、あらゆる非常駐属性を削除する。それらの属性を０の長さにする。ユーザデータ属性を除き、あらゆる常駐属性を削除する。それらの属性を０の長さにする。属性リストが更新されることを確実にする必要がある。属性リストが更新されることを確実にする必要がある。残っているファイルが依然として有効であることを検証する必要がある。属性が含まれる可能性があるあらゆるインデックスから属性を削除する。

ＳＣＢを有するディスク上の矛盾−ディスク上の属性をまず検証し、必要な変更を行う。次に、正しいディスク上の変更でＳＣＢおよびＦＣＢを更新する。

メモリ内の構造の矛盾だけ−ＳＣＢおよびＦＣＢをディスクから再び更新する。

サポートされる値より高い割り当て長（ａｌｌｏｃａｔｉｏｎ ｌｅｎｇｔｈ）。マッピングペアおよび最高のＶＣＮ値に照らしてその値を検証することができる。

複合属性
複合属性は、完全なＮＴＦＳ属性を構成するすべての基本属性のセットである。

内部属性検証により、属性のすべてに自己矛盾がないことが確認される。自己矛盾がない場合、ＮＴＦＳは、そのことを反映するようにＳＣＢおよびＦＣＢを更新する。外部属性検証には、すべての属性に関してＭＦＴをスキャンすることが関わる。これには、ＭＦＴのフルスキャンが関わるので、代わりに外部ファイル検証を行う理由はまったくない。

以下のエラーは、複合属性の破損を示す。すなわち、
割り当てサイズを超えたファイルの断片に関する基本属性が存在する−すべての不必要な断片を削除する。

複合属性内の欠落した属性−まず内部属性検証を行う。これが矛盾のない属性に解決された場合、そのことを反映するようにＳＣＢを更新する。それ以外の場合、外部ファイル検証に進む。

矛盾のあるＳＣＢ値−内部属性検証を行う。

ＭＣＢが、長さ０の範囲を有する−内部属性検証を行う。

属性コンテンツ
自己回復ＮＴＦＳが、ＮＴＹＳメタデータ、またはＮＴＦＳメタデータを有する属性の部分を使用して属性の内容を検証する。例えば、修復ポイントが、修正されたデータおよびユーザ定義データを含む。ＮＴＦＳは、いずれの属性のユーザ部分を保存しようとする試み、または検証しようとする試みもまったく行わない。

ＮＴＦＳメタファイル内の特定の属性の内容検証は、別の場所で説明する。

非常駐属性
ブートファイル以外のファイル内のＬＣＮ０−属性が無効であり、０の長さに設定されるか、削除されなければならない。その後、内部ファイル検証を行う。

＄ＳＴＡＮＤＡＲＤ−ＩＮＦＯＲＭＡＴＩＯＮ
無効な＄ＳＴＡＮＤＡＲＤ−ＩＮＦＯＲＭＡＴＯＮ−内部ファイル検証を行う。標準の情報を再構築する。

＄ＡＴＴＲＩＢＵＴＥ−ＬＩＳＴ
属性リスト長が、既存の属性を切り捨てる−外部ファイル検証を行う。

属性リストエントリが、０の長さを有する−外部ファイル検証を行う。属性リストエントリが、ファイルの中に入っていない−内部ファイル検証を行う。

属性リストが、ファイルレコードの中に入っている欠落したエントリである−外部ファイル検証を行う。

＄ＤＡＴＡ
＄ＤＡＴＡ属性−ＮＴＦＳは、壊れたユーザデータストリームを修復する場合にだけ、あるアクションを行う。ＮＴＦＳは、属性が存在することが要求される場合、ゼロの長さの属性を作成し、属性が現在、存在して、壊れている場合、切り捨てて０にするか、または完全に削除する。

＄ＲＥＰＡＲＳＥ−ＰＯＩＮＴ
無効な＄ＲＥＰＡＲＳＥ−ＰＯＩＮＴ−ファイルおよび再解析インデックスから属性を削除する。再解析ポイントがまったく存在しないことを示すようにＦＣＢ／ＳＣＢを更新する。

＄Ｒｅｐａｒｓｅ属性−接合ポイントだけが、ディレクトリ上にあることが可能であり、ディレクトリは、空でなければならない。＄Ｒｅｐａｒｓｅ属性と＄ＥＡ属性がともに、同一のファイル上、または同一のディレクトリ上に存在することは不可能である。再解析タグは、ＤＵＰＬＩＣＡＴＥＤ−ＩＮＦＯＲＭＡＴＩＯＮの一部である。

＄ＥＡおよび＄ＥＡ−ＩＮＦＯＲＭＡＴＩＯＮ
＄ＥＡと＄ＥＡ情報は、どちらかが存在する場合、ともに存在しなければならない。ＥＡ情報は、ファイルに関するＤＵＰＬＩＣＡＴＥＤ−ＩＮＦＯＲＭＡＴＩＯＮの中にも存在する。ファイルに関するＥＡは、ディレクトリエントリの中のＥＡ情報と整合性がある必要がある。内部ＥＡ検証により、ＥＡおよびＥＡ−ＩＮＦＯＲＭＡＴＩＯＮが有効な属性であること、ＥＡがうまく構成されていること、およびディレクトリ情報の中のＥＡ情報が合致することが確認される。さらに、ファイルの中に＄ＲＥＰＡＲＳＥ属性は、まったく存在しない。

ＥＡ属性が欠落している−内部ＥＡ検証を行う。

インデックス
属性に対するインデックスは、ファイル内の属性に対応するＩｎｄｅｘの中にエントリを有する。例は、ファイル名、再解析ポイント、およびオブジェクトＩＤである。以下のいくつかのエラーは、すべてのインデックスに当てはまるが、インデックス固有のエラーは、属性に対するインデックスだけに当てはまる。

それらのインデックスの内部検証には、インデックスが正しい形式であり、適切に並べ替えられていることを確認することが関わる。さらに、インデックス内のエントリは、ファイル内に対応する属性を有する。

外部検証は、そのＩｎｄｅｘに対応するエントリを探して、ＭＦＴのフルスキャンを行うことに関わる。

インデックスヘッダ
インデックスヘッダオフセットが、バッファの外をポイントする−完全なＭＦＴスキャンを介してインデックスを再構築する。

ヘッダがいずれのエントリもポイントしない−完全なＭＦＴスキャンでインデックスを再構築する。ｂｔｒｅｅをシャッフル（ｓｈｕｆｆｌｅ）することに基づく、またはすべてのインデックスバッファを順に調べ（ｗａｌｋ）、構築中の新たなインデックスにエントリを追加することによって同じ場所にｂｔｒｅｅを再構築することに基づく最適化を考慮されたい。

最後のインデックスエントリより前に終端レコードに達する−完全なＭＦＴスキャンでインデックスを再構築する。最適化には、偽の終端レコードを超えるエントリだけを孤立させること、または別の終端レコードが存在するかどうかを試験することが含まれる。

インデックスバッファ
ＩｎｄｅｘＢｌｏｃｋ内で上位３２ビットが設定されている−そのインデックスを破棄し、ＭＦＴスキャンでインデックスを再構築する。無効なビットを無視することを検討することを考慮され、内部検査によりインデックスエントリが有効であることが示される場合、０にリセットされたい。

ＩｎｄｅｘＢｌｏｃｋ番号の下位３２ビットの値が誤っている−完全なＭＦＴスキャンを介してインデックスを再構築する。ＩｎｄｅｘＢｌｏｃｋフィールド内の破損に基づく最適化だけを考慮されたい。これは、その値を予期される値に設定した後に、内部インデックス検証によって行うことができる。

有効なヘッダ署名−完全なＭＦＴスキャンを介してインデックスを再構築する。署名の破損に基づく最適化だけを考慮されたい。

無効なＵＳＡヘッダおよびアレイ−完全なＭＦＴスキャンを介してインデックスを再構築する。

空のリーフノードを有するインデックスバッファ−内部インデックス検証を行う。

インデックスエントリ
内部インデックスエントリ長が、エントリの長さを超えて延びる−エントリを削除し、内部インデックス検証を行った後、オーファン（ｏｒｐｈａｎｓ）を探す完全なＭＦＴスキャンを行う。ＭＦＴスキャンは、ＮＴＦＳがインデックスからファイル参照を回復することができる場合、ＮＯＯＰすることができる。

既に存在するエントリを追加しようと試みること−これは、多分、論理内のバグを示す。エントリが存在するかどうかを確かめる検査が既に存在しているはずである。実際の問題が存在する場合、修正は、インデックスの内部検証を行った後、孤立したエントリを探すＭＦＴスキャンに進むことである。

ＮＯＤＥ値の不一致−インデックスバッファ内のすべてのエントリが、合致する値を必要とする。完全なＭＦＴスキャンを介してインデックスを再構築する。バッファ上のいずれかのエントリ内のノードビットの破損に基づく最適化を考慮されたい。また、現在のエントリを削除することができるか、内部検証を実行することができるかも考慮されたい。これは、ＭＦＴスキャンがオーファンを探す間、インデックスを使用できない状態のままにする。

長さ０を含む無効なインデックスエントリ長−完全なＭＦＴスキャンを介してインデックスを再構築する。単一の不良エントリを抽出する方法を考慮されたい。これは、そのエントリがリーフである場合、インデックスバケット（ｂｕｃｋｅｔ）の中に残っているエントリを破棄すること、ならびにオーファンだけを探すＭＦＴスキャンによって行うことができる。

予期されるインデックスビットマップが欠落している−他のすべてのインデックス属性が存在している場合、ビットマップは、ｂｔｒｅｅを順に調べる（ｗａｌｋ）することによって再構築することができる。これが失敗した場合、完全なＭＦＴスキャンが必要とされる。

インデックスバッファが、終端エントリだけを含む−完全なＭＥＴスキャンでインデックスを再構築する。ｂｔｒｅｅをシャッフルすること、またはすべてのインデックスバッファを順に調べ、構築中の新たなインデックスにエントリを追加することによって同じ場所にｂｔｒｅｅを再構築することに基づく最適化を考慮されたい。

バランスが取れていないｂｔｒｅｅ−完全なＭＦＴスキャンでインデックスを再構築する。すべてのインデックスバッファを順に調べ、構築されている新たなインデックスにエントリを追加することにより、同じ場所でｂｔｒｅｅをシャッフルすること、またはｂｔｒｅｅを再構築することに基づく最適化を考慮する。

レコード割り当てビットマップ
ビットが、設定しようと試みた時点で既に設定済みである−レコード割り当てパッケージに初期化解除（uninitialize）を行い、ディスクから読み取る。レコード割り当てパッケージを再初期化した同一のルーチンにおいてその壊れたビットが見つかった場合、ハードエラーである。

ビットが、クリアしようと試みた時点で既にクリア済みである−エラーなしであるが、ビットをクリアする動作を再びログ記録する。

基本ファイルレコード
基本ファイルレコードは、ＩＮ−ＵＳＥというマークが現在、付けられているあらゆるファイルレコードである。基本ファイルレコードは、ファイル全体を表すことも、ファイルの属性のいくつかだけを表すことも可能である。

Ａｔｔｒｉｂｕｔｅが、ファイルレコード境界にまたがる−最後の有効な属性を超えたところでＳＥＮＤ属性を挿入する。その後、完全なファイル検証を必要とする。

ＣｈｅｃｋＦｉｌｅＲｅｃｏｒｄから見つかった、壊れたレコード−各属性を検証し、属性が正しくレイアウトされていることを確かめ、ヘッダ値を検証する。結果が１つの属性も含まない場合、ＩＮ−ＵＳＥではないというマークをファイルレコードに付ける。そのレコードが参照するファイルの内部ファイル検証を行う。

Ｉｎ−Ｕｓｅビットが設定されていない−そのファイルレコードに対する外部参照が存在する場合、ＭＦＴビットマップビットが設定されているかどうかをチェックする。設定されたビット、または他の指示が、そのファイルレコードが使用中のはずであることを示唆する場合、ファイルレコード内でそのビットをリセットする。そのように示唆しない場合、そのレコードに使用中ではないというマークを付け、内部ファイル検証を行う。必要な場合、外部ファイル検証まで拡張する。

ファイル署名が壊れている−そのファイルレコード内のすべての属性を削除する。ファイルが既知である場合、ファイルに対して完全なファイル検証を行う。ファイルが未知である場合、そのファイルを参照するインデックスエントリを探すファイルスキャンを行う必要がある可能性がある。見つかった場合、既知のファイル断片を再構築し、通知を生成する。ファイル署名に破損を制限することに基づく最適化を考慮されたい。

ＢＡＡＤファイル署名、不良なＵＳＡヘッダ、不良なオフセットフィールド−そのファイルレコード内のすべての属性を削除する。ファイルが既知である場合、ファイルに対して完全なファイル検証を行う。ファイルが未知である場合、ファイルを参照するインデックスエントリを探すフルスキャンを実行する必要がある可能性がある。見つかった場合、既知のファイル断片を再構築し、通知を生成する。

不良ファイルレコード検査−そのファイルレコード内のすべての属性を削除する。ファイルが既知である場合、ファイルに対して完全なファイル検証を行う。ファイルが未知である場合、ファイルを参照するインデックスエントリを探すフルスキャンを実行する必要がある可能性がある。見つかった場合、既知のファイル断片を再構築し、通知を生成する。

Ｃｏｍｐｌｅｔｅ Ｆｉｌｅ
Ｃｏｍｐｌｅｔｅ Ｆｉｌｅは、Ｂａｓｉｃ Ｆｉｌｅ Ｒｅｃｏｒｄ、非常駐属性に関する外部割り当て、および外部参照のすべてである。ディスク上のほとんどのファイルは、ユーザファイルまたはユーザディレクトリである。システムファイルの特定のプロパティは、別の場所で説明する。ファイルおよびディレクトリは、以下の属性を有する。

ＭＦＴビットマップは、ファイル内の各ファイルレコードに対して設定された対応するビットを有する。

ファイルに関するすべてのファイルレコードは、正しい形式であり、ＩＮ−ＵＳＥビットが設定されている。

ベースレコードは、そのベースレコードとして０を有する。

その他のレコードは、ベースレコードを参照する。

ＶＩＥＷ−ＩＮＤＥＸビットが設定されていない。

ＦＩＬＥ−ＮＡＭＥ−ＩＮＤＥＸにより、それがユーザディレクトリであることが示される。

ファイルは、次の要求される属性を有する（＄ＳＴＡＮＤＡＲＤ−ＩＮＦＯＲＭＡＴＩＯＮ、＄ＦＩＬＥ−ＮＡＭＥ）。

＄ＦＩＬＥ−ＮＡＭＥが、ＤＯＳビットまたはＮＴＦＳビットとともに存在する場合、他のフラグを有する＄ＦＩＬＥ−ＮＡＭＥが存在しなければならない。

ユーザファイルは、１つの名前のない＄ＤＡＴＡストリームを有さなければならない。ユーザディレクトリは、ファイル名、＄ＩＮＤＥＸ−ＲＯＯＴとともに、他の要求されるインデックス属性を有さなければならない。それらの１つだけが、いずれかのユーザファイルまたはディレクトリの中に存在することが可能である。

次の属性が存在することが可能である（＄ＡＴＴＲＩＢＵＴＥ−ＬＩＳＴ、＄ＯＢＪＥＣＴ−ＩＤ、＄ＳＥＣＵＲＩＴＹ−ＤＥＳＣＲＩＰＴＯＲ、＄ＲＥＰＡＲＳＥ、＄ＥＡ−ＩＮＦＯＲＭＡＴＩＯＮ、＄ＥＡ、名前の付いた＄ＤＡＴＡ、＄ＬＯＧＧＥＤ−ＳＴＲＥＡＭ）。重複する名前を有する＄ＤＡＴＡストリームは、許されない。

内部ファイル検証は、ファイルに関するすべての情報が、ベースファイルレコード、ならびに、存在する場合、属性リストを順に調べることによってＮＴＦＳが見つけることができるファイルレコードの中に入っていることを前提とする。内部ファイル検証は、そのファイルに戻る外部の参照（すなわち、そのファイルに対するディレクトリ内のエントリ）に関わらない。

次のレベルの検査は、インデックス付きの属性のそれぞれ、およびセキュリティ参照が、対応する有効な外部データを有することを確認する。

外部ファイル検証は、そのファイルに属するファイルレコードを探してＭＦＴ全体を順に調べる。

以下のエラーがファイルに固有である。

ファイルが、ディレクトリというマークを付けられているが、＄ＩＮＤＥＸ−ＲＯＯＴ属性を欠いている−名前のないデータストリームおよび／または他の＄ＩＮＤＥＸ属性を探すことにより、ディレクトリビットが誤ってないかどうか調べ、ファイルが、依然としてディレクトリのように見える場合、空のディレクトリを作成し、ディレクトリ内の他のファイルに関してＭＦＴをスキャンする。他の＄ＩＮＤＥＸ属性を削除する。

ユーザファイルに関する有効なリンクが存在しない−有効なプライベートリンクが存在するかどうか調べる必要がある。名前を挿入する必要がある場合、ルートにおけるＦＯＵＮＤディレクトリの中に名前を入れる。

＄ＳＴＡＮＤＡＲＤ−ＩＮＦＯＲＭＡＴＩＯＮ属性が存在しない−値のほとんどは、ファイルの残りの部分から推測することができる。このエラーをタイムスタンプ、属性、およびセキュリティを更新することのように扱う。

属性が、ファイル内に存在するが、Ｉｎｄｅｘ内に存在しない−インデックスの中に対応するエントリを入れる。競合する名前（すなわち、ファイル名）が、既にインデックス内に存在する可能性がある。その場合、ファイルに関するリンクは、「Ｆｏｕｎｄ」ディレクトリの中で作成されなければならない。

別の場所でインデックス付けされた予期される属性を見つけることができない−可能な場合、ファイルの既存の状態と競合しないという条件付きで、対応する属性を挿入する。可能でない場合、インデックス内のエントリを削除する。ファイルに対する内部検査を行う。

予期される属性を見つけることができない（別の場所でインデックス付けされていない）−内部ファイル検証を行い、変更に合致するようにＳＣＢ／ＦＣＢを更新する。

必須の属性リストを欠いている−完全な外部ファイル検証を行う。

長い名前／短い名前ペアの１つの属性を欠いている−まず、孤立したメンバを有するディレクトリ内でスキャンを行い、他の名前がそこに存在するかどうかを調べる。存在する場合、その名前をファイルに組み込む。長い名前が存在し、有効な短い名前である場合、長い名前／短い名前のファイル名に変換する。長い名前が存在し、有効な短い名前ではない場合、有効な短い名前を生成する。短い名前が存在する場合、単にその名前を長い名前／短い名前にする。

ログファイル破損
ログが開始されない
再起動中に読み取りが行われない
ハードウェア障害対データ破損エラー
ルートディレクトリ
ルートディレクトリは、その他のディレクトリのプロパティのすべてに加え、以下を有する。すなわち、
ルートディレクトリは、ルートディレクトリ自体に関するエントリを含む。

ルートディレクトリは、システムファイルのそれぞれに関するエントリを有する。

ルートディレクトリは、ＳＹＳＴＥＭビットとＨＩＤＤＥＮビットがともに設定されている。

ルートディレクトリ独自の名前は、「．」である。

ルートディレクトリは、常にディレクトリである。

ボリュームビットマップ
既に設定済みのビットを設定しようと試みる−これは、ビットがキャッシュされた情報から来ている場合、ＮＴＦＳが既に再試行を行っているので、ハード障害のはずである。

ＬＣＮ０を空き（ｆｒｅｅ）に設定しようと試みる−ファイルに対して内部ファイル検証を行う。属性がＬＣＮ０を有するべきでない場合、属性を０の長さに設定する。

セキュリティファイル
壊れた記述子−バックアップ記述子を検査する。依然として壊れている場合、壊れた記述子を削除し、かつ、合致するファイルを探してＭＦＴを順に調べる必要がある。正しい順序は、まずＭＦＴを順に調べ、セキュリティを変更することである。壊れた記述子のテーブルを保持し、そのタイプ上での合致を許さない。

孤立した記述子−削除することができるが、ＴＸＦがそのエントリを必要としていないことをＴＸＦに確認する必要がある。

具体的なエラーには、以下が含まれる。すなわち、
Ｋｅｙ Ｌｅｎｇｔｈが、セキュリティＩＤインデックスの中のＳＥＣＵＲＩＴＹ−ＩＤのサイズではない。

Ｄａｔａ Ｌｅｎｇｔｈが、セキュリティハッシュインデックスの中のＳＥＣＵＲＩＴＹ−ＤＥＳＣＲＩＰＴＯＲ−ＨＥＡＤＥＲのサイズではない。

属性定義ファイル
欠落した＄ＤＡＴＡ属性−属性テーブルを再書き込みする。これは、ポスティングを行うことなしに同じ場所で行うことができる。ただし、ＮＴＦＳが、まず修復される必要がある連鎖的な破損に行き当たった場合、これが行われていることを把握している必要がある。

再解析ポイントファイル
再解析ポイントファイルは、単一のインデックス「＄Ｒ」から成る。インデックスは、再解析ポイントタグをＮｔｆｓファイルＩＤにマップする。ファイルはすべて、正しい形式の属性およびファイルレコードを有さなければならない。再解析ポイントは、以下のプロパティを有する。すなわち、
ＶＩＥＷ−ＩＮＤＥＸビットがヘッダ内で設定されている。ＦＩＬＥ−ＮＡＭＥ−ＩＮＤＥＸビットが設定されていてはならない。ＳＹＳＴＥＭ−ＦＩＬＥビット設定。

ファイル名は、＄Ｒｅｐａｒｓｅであり、＄Ｅｘｔｅｎｄディレクトリの中に含まれる。

再解析ポイントには、クォータ（ｑｕｏｔａ）がまったく課せられない。

再解析ポイントは、Ｓｙｓｔｅｍ／Ａｄｍｉｎセキュリティ記述子を有する。

再解析ポイントは、次の属性だけを有する（＄ＳＴＡＮＤＡＲＤ−ＩＮＦＯＲＭＡＴＩＯＮ、必要な場合、＄ＡＴＴＲＩＢＵＴＥ−ＬＩＳＴ、＄ＦＩＬＥ−ＮＡＭＥ、＄Ｒに関する＄ＩＮＤＥＸ−ＲＯＯＴ、＄Ｒに関する＄ＩＮＤＥＸ−ＡＬＬＯＣＡＴＩＯＮ、および＄Ｒに関する＄ＢＩＴＭＡＰ）。

＄ＩＮＤＥＸ−ＲＯＯＴ属性は、そのインデックスがビューインデックスであり、照合順序（ｃｏｌｌａｔｉｏｎ）値が正しいことを示す。

内部再解析ファイル検証により、以上が存在し、以上だけが存在することが確認される。Ｉｎｄｅｘは、正しい形式であり、正しく並べ替えられていなければならない。内部再解析ファイル検証により、＄Ｒインデックスの中の再解析タグキーが有効であり、それらのキーがポイントするファイルＩＤが、ＭＦＴの有効な部分の範囲内にあることも検証される。Ｉｎｄｅｘが壊れていることが分かっている（実際の修復が行われている）場合、そのインデックスにアクセスする要求は、ブロックされるか、または拒否される。検証が行われているが、破損がまったく見つかっていない場合、インデックスにアクセスする要求は、通常の同期制約の下で行われる。

次のレベルの検査は、インデックスの中の各エントリを対象とし、参照されるファイルＩｄが、実際に使用中のユーザファイルであること、そのＩｄが対応する再解析属性を有すること、およびその属性が有効な再解析ポイントを含むことを確認する。ファイル上の再解析タグは、再解析ポイントにおけるタグと一致しなければならず、ＳＲインデックスの中のタグと一致しなければならない。

最終レベルの検査は、インデックスにおいて対応するエントリを有さないファイル群において孤立した再解析ポイント属性を探す完全なＭＦＴスキャンである。

以下のエラーが、適切な修復とともに、＄Ｒｅｐａｒｓｅファイルに固有である。すなわち、
＄Ｒｅｐａｒｓｅファイルの中で対応するエントリを見つけることができない−孤立した再解析ポイントを有するファイルの内部検証を行う。次に、＄Ｒｅｐａｒｓｅファイルの内部検証を行う。最後に、必要に応じて、再解析ポイントを再解析インデックスの中に挿入する。

ページングファイル
ページングファイルに対して入出力を実行することができないあらゆる障害は、システムに致命的である。その場合、行うことができる修復は、限られている。

マッピングペアが、完全に読み込まれていない−現行の要求を拒否し、作業項目をポスティングする。ファイルの内部検証を行った後、割り当て情報をディスクからＭＣＢに注意深く読み込む。これにより、システムに障害が生じる可能性がある。

ＭＦＴ構築
ファイルレコード０が、利用可能であるように見える−ＭＦＴスキャンを行ってＭＦＴビットマップを再構築する。

ＭＦＴにおける穴（ｈｏｌｅ）に対する参照−穴に対するクラスタを生成する。初期化解除が行われたファイルレコードをポイントするファイルを検証する。

ＭＦＴ、ならびにＭＣＢにおけるＭＦＴマッピング
第１のＭａｐｐｉｎｇを見つけることができない−ＭＦＴとＭｉｒｒｏｒの両方の中で初期ファイルレコードを読み取ることにより、マッピングを確認する。有効なエントリを見つけることができない場合、完全なディスクスキャンを行う。

ＭＦＴビットマップ
＄ＢＩＴＭＡＰが存在しない−ＭＦＴスキャンを行い、ビットマップを再構築する。そのビットマップを＄ＭＦＴファイルの中に挿入する。

中止の失敗（Ｆａｉｌｅｄ Ａｂｏｒｔ）
中止の失敗は、ボリュームを壊れた状態のままにする可能性がある。トランザクションに関わる個々のストリームを識別することができる場合、それらのストリームだけに対して修復スキャンを実行することが可能である。それ以外の場合、完全なボリュームスキャンを行うことが必要である可能性がある。一部のエラーは、ユーザがそれらのエラーに再びアクセスした際にＮＴＦＳが問題を検出するので、無視しても安全である可能性がある。

以下の具体的なエラーが、中止を処理する際に生じる可能性がある。すなわち、
無効なログレコードの検査
再起動失敗
再起動を実行できないことにより、ボリュームが無効な状態のままになる可能性がある。ＮＴＦＳは、マウントを完了させるが、ボリュームにダーティというマークが付けられたままにする、または完全なボリューム修復をスケジュールすることにより、その状態から回復を行うことができる。また、単にボリュームを壊れた状態のままにして、個々のエラーが検出され、見つかった際に修正されるのを許すことも可能である。

再起動状態を初期化すること
以下の具体的なエラーが、再起動状態を初期化する際に生じる可能性がある。すなわち、
ログにおけるＬＦＳ構造の内部矛盾。ＬＦＳは、現行では、それらのケースで破損ステータスを発生させる。

ＮＴＦＳ再起動レコードを読み取ることのエラー。

ＮＴＦＳ再起動レコード内の再起動テーブルに関するログレコードのいずれかを読み取ることのエラー。

ディスクに書き込まれた再起動テーブルのいずれかに関する無効なＮＴＦＳレコードヘッダ。

ログレコード内に書き込まれた再起動テーブルの破損。

属性名エントリが、基礎にあるオープン属性エントリに対する無効なインデックスを有する。

分析走査（ｐａｓｓ）を実行すること
次の具体的なエラーが、分析走査を実行している際に生じる可能性がある。すなわち、ディスクからログレコードを読み取ることができないこと。無効なログレコードが、ディスクから読み取られること。

ダーティなページテーブルを初期化すること
以下の具体的なエラーが、ダーティなページテーブルを初期化している際に生じる可能性がある。すなわち、
ダーティなページエントリが、無効な属性インデックスを参照する。

ダーティなページエントリが、存在しない属性を参照する。

再実行走査を実行すること
以下の具体的なエラーが、再実行走査を実行している際に生じる可能性がある。すなわち、
ディスクからログレコードを読み取ることができない。

ディスクから無効なログレコードが読み取られる。

ログレコードが、無効な属性インデックスを参照する。

ログレコードが、対応する属性が存在していない場合に属性インデックスを参照する。

ここで、構造上のインプリメンテーションを説明する。さらなる破損が見つかった場合、ロック（ｌｏｃｋｉｎｇ）およびアクションを含む。

変更をログ記録する最も単純な方法は、ファイルレコード全部、インデックスバッファ、非常駐属性をログ記録することである。

インデックスが再構築中である場合、インデックスの中のエントリを有効として扱うことができる。通常の処理においてオーファンを見つけた場合、そのオーファンは、単に、フルスキャンが行われているのと同時に追加することができる。ただし、その間、ユーザが生成したエントリが追加されるのをブロックしなければならない。

ＭＦＴ再構築
完全なＭＦＴ再構築には、ＭＦＴファイルレコードを探して、ボリューム上でクラスタのフルスキャンを行うことが関わる。

ＮＴＦＳは、この探索がいつ行われることが可能であるが、どのような「ファイルレコード」が認識されるかに関して、いくつかの制限を課す。ＮＴＦＳは、別のＮＴＦＳボリュームのイメージが、現行のボリューム上のファイルとして格納されている状況を見出す可能性がある。また、現行のボリュームは、スナップショット情報、またはデフラグ動作からの陳腐化したＭＦＴレコードを含む可能性もある。

ボリュームは、ＮＴＦＳバージョン４．０ボリューム以降でなければならない。これは、新たなファイルレコードが、ヘッダの中に埋め込まれたファイルレコード番号を常に有することを意味する。

ＮＴＦＳは、アップグレードプロセスの一環としてスキャンを完了させて、正しいファイルレコード番号およびボリューム識別子を各ＩＮ−ＵＳＥファイルレコードの中に格納する。このスキャンが完了すると、完全なＭＦＴ再構築が可能であることを示すフラグが、ボリュームＤＡＳＤファイルレコードの中で設定される。

ＭＦＴ再構築は、以下のステップから成る。すなわち、
ＮＴＦＳをファイルシステムタイプとして識別するブートセクタ検証。注−ブートセクタからクラスタサイズを算出することができない場合、ＮＴＦＳは、既定のサイズに基づいてマッピングを構築して、後に実際のクラスタサイズを算出しなければならない。バックアップブートセクタを初期認識段階で使用して、ＭＦＴロケーションおよびクラスタサイズの可能な検証、または正しいバックアップコピーを提供することができる。

ブートセクタがポイントするＭＦＴレコードを介して完全なマッピングペアを構築しようと試みる。ＭＦＴをこのやり方で再構築することが不可能な場合、これにより、何も見つからない結果となる可能性がある。これは、ＮＴＦＳがゼロからＭＦＴを再構築している場合、予測されるエラーである。

マッピングペアが、以上のステップから不完全である場合、ディスクスキャンを開始する。可能なファイルレコードを探して、ディスクを読み取ることを始める。可能なファイルレコードの中のＵＳＡ署名、ファイルレコード番号、およびボリューム識別子が使用される。可能な偽のヒット（ｓｐｕｒｉｏｕｓ ｈｉｔｓ）には、以下が含まれることが可能である。すなわち、
・ＭＴＦミラー内のファイルレコード
・ＭＦＴデフラグからの古いＭＦＴデータ
・再フォーマットに先立つボリュームの以前のインスタンスからの陳腐化したデータ
・ボリュームスナップショットデータ
・ファイルとして格納されたＮＴＦＳディスクイメージ
・有効なＭＦＴレコードのように見える（場合により、悪意のある）ユーザファイルの中のデータ
ＮＴＦＳは、それらのレコードを見つけると、ボリューム識別フィールドでボリューム候補にグループ化する。ＮＴＦＳは、可能なボリュームの別々のコピーを蓄積し、可能な場合、それらを削除する。各レコードが見つかると、既定のクラスタサイズを使用するそのレコードの場所が、そのボリューム識別子としてＭＣＢの中に格納される。競合が生じた（ＭＣＢ内のその場所に既にエントリが存在する）場合、ＮＴＦＳは、ページ上のＬＳＮを検査し、そのページをより高いＬＳＮで使用する。ＭＦＴミラー内のファイルレコードは、それらのレコードがＭＦＴの一部であると想定する場合、有効に見えるが、誤った場所に存在する。ＮＴＦＳは、その時点までに見つかった各候補ボリュームの最初の０ｘ１０フィールドレコードに関するマッピングの２つのコピーを保持する。ＭＦＴ自体を記述するファイルレコードが見つかった場合、ＮＴＦＳは、＄ＤＡＴＡ属性を探してファイルレコードをスキャンし、別個のＭＣＢの中で見つかった部分的マッピングを記憶しておく。

ボリュームスキャンが完了すると、ＮＴＦＳは、解決すべき複数のボリューム候補を有する可能性がある。各候補に関して、ＮＴＦＳは、ボリュームスキャンから以下を保存している。すなわち、
・ボリューム識別子−ボリュームＤＡＳＤおよびファイルレコードの中に格納された
・自己記述ＭＦＴファイルレコードからの部分的ＭＣＢ
・ディスク上で見つかったＭＦＴファイルレコードからの部分的ＭＣＢ
・ミラー範囲内の代替の可能な有効なＭＦＴレコードに関する部分的ＭＣＢ
次に、ＮＴＦＳは、以上の候補のそれぞれを分析して、そのボリュームに関する実際のＭＦＴである可能性がある候補を見出す必要がある。ＮＴＦＳは、ＭＦＴ、またはＭＦＴミラーに関するファイルレコードを見つけることができた場合、それらのレコードが、それらのレコード独自のマッピングペアによって記述されたオフセットにあるかどうかを検証することができる。これは、最初のレベルの認証である。１つのボリューム候補だけしか存在しない場合、ＮＴＦＳは、見つかったすべての有効なファイルレコードがそのボリュームに属するものと考えることができる。

ＮＴＦＳは、ＭＦＴ、またはシステムファイルのいくつかを再構築している間、利用可能な空きクラスタのいくらかの知識を必要とする可能性がある。これは、ボリュームビットマップストリーム内で有効な＄ＤＡＴＡ属性が存在しない時点である可能性がある。ボリュームのサイズにより、ビットマップの完全なコピーをメモリの中に格納することが不可能になる可能性がある。代わりに、ＮＴＦＳは、既知のファイルレコードをスキャンして、ボリュームビットマップのサブセットに属する割り当て済みのクラスタを探すことができる。この部分的な情報を使用して、新たなクラスタをＭＦＴ、ボリュームビットマップ、およびログファイルに割り当てることができる。

ＭＦＴのあらゆる穴を埋めるのに十分な空きクラスタを割り当てる。それらのクラスタをＭＦＴに関するマッピング情報に追加し、初期化解除が行われたファイルレコードを使用して実際のクラスタを初期化する。

ＭＦＴビットマップ再構築
ＭＦＴビットマップ属性が失われた場合、ＮＴＦＳは、その属性をゼロから再構築することができる。これは、ＭＦＴに関するマッピングペアを構築するＮＴＦＳスキャンが行われた後に行われる。ＭＦＴビットマップに属するクラスタが失われた場合、ＮＴＦＳは、以下のステップを行う。すなわち、
・ビットマップに必要とされるクラスタの数を計算する。

・必要なクラスタを見つける。これは、空きクラスタに関して既知のＭＦＴレコードをスキャンすることに関わる。これは、範囲ごとの別々のスキャンを要する可能性がある。

・この目的でマッピング情報を蓄積し、ＭＦＴビットマップに関するＳｃｂの中に格納する。

・ビットマップをすべて０ｘｆｆｆｆｆｆｆｆに初期化する。

・初期化解除が行われたレコードを探してＭＦＴの中で既知のファイルレコードをスキャンし、ＭＦＴビットマップの中でそれらのビットをクリアする。

・対応するレコードがまだその状態になっていない場合でも設定されていなければならないビットを、設定されたままにする。これには、最初の０ｘ１０システムファイルレコードが含まれる。

ＭＦＴビットマップは、この時点で、完全なオンラインｃｈｋｄｓｋスキャンの一環として通常の確認走査の準備ができている。

ＭＦＴミラー再構築
ＭＦＴミラーファイルは、失われた場合、ＭＦＴが完全に再構築された後にＭＦＴから再構築される。

Ｌｏｇｆｉｌｅ再構築
ＮＴＦＳ Ｌｏｇｆｉｌｅが、ＮＴＦＳメタデータを変更する際に使用される。ログファイルは、ログ記録を必要とする修復を行う際に、初期化されており、利用可能である必要がある。ログファイルは、壊れている場合、そのログを使用して修復を行う前に、修復されなければならない。必要なのは、ログに関するマッピング情報、およびＳＣＢが、ディスク上の有用な場所をポイントすることだけである。ログに関するファイルレコードは、その後で修復することができる。

ログファイルには、いくつかのタイプの破損が存在する。それらは、内的、外的の両方であることが可能である。すなわち、
ログファイルを記述するメタデータが壊れている（外的）−これは、ＮＴＦＳが、ログファイルに関するファイルレコードを失った場合か、またはログを記述するメタデータが壊れている場合である。これらのケースのそれぞれにおいて、ＮＴＦＳは、ログファイルとして使用するのに十分な数のクラスタを見つける必要がある。次に、ＮＴＦＳは、そのマッピングを使用してＳｃｂを構築し、ログ用のクラスタを初期化する。

ログファイル内のデータが壊れている（内的）−これがマウント中、または再起動中に生じた場合、ＮＴＦＳは、ログ全体を壊れているものとして扱い、再初期化することができる。ボリュームが既にアクティブである場合、ＮＴＦＳは、エラーを無視するが、現行のトランザクションの一部であるあらゆるファイルに壊れているというマークを付け、それらに対して確認スキャンを実行することができる。

ログファイルを再初期化することには、以下が関わる。すなわち、
・０ｘｆｆｆｆｆｆｆｆというパターンをログ全体に書き込む。これは、それらのクラスタの中に既に存在する陳腐化したデータがＮＴＦＳを混乱させないことを確実にする。

・ボリューム上の既知の最高のＬＳＮをＬＦＳに送る。すると、ＬＦＳは、ログファイルを初期化して、ログファイルが、その値よりも高いＬＳＮを生成するようにする。

完全なボリューム修復
これは、ｃｈｋｄｓｋが現在、行っているフルスキャンに相当する。

ボリューム利用可能
ＮＴＦＳボリュームは、管理者が、マウント済みのボリュームに対してその要求を開始した場合、可能な範囲で利用可能である。ＮＴＦＳがマウントパスに深刻な破損を検出した場合、マウントは、ボリュームが使用可能な状態になるまでブロックすることができる。

何らかの修復スキャンが行われていて、ユーザがボリューム上でアクティブである場合、ユーザは、ユーザの操作が完了するのを妨げる破損に直面する可能性がある。次善策（ｗｏｒｋａｒｏｕｎｄ）が利用可能な場合、ユーザの要求は、完了させることができる。利用可能でない場合、ユーザの要求は、フルスキャンの背後でブロックされる。

予備状態
ＮＴＦＳは、フルスキャンを実行するためにあるリソースを有さなければならない。フルスキャンを開始することができるにはまず、以下が、用意されていなければならない。すなわち、
・完全なＭＦＴに関するマッピング情報（メモリ内のＭＣＢ情報と、利用可能な場合、自己記述ＭＦＴファイルレコードの中のマッピングペアの間における矛盾を探す）
・ＭＦＴビットマップに関するマッピング情報
・ＭＦＴミラーに関するマッピング情報
・ＮＴＦＳログファイルに関するマッピング情報
・ＮＴＦＳボリュームビットマップに関するマッピング情報
・ボリュームビットマップが疑わしいケースで、既知の利用可能な空きクラスタのいくらかのキャッシュ
・利用可能な場合、Ｂａｄ Ｃｌｕｓｔｅｒファイルからの既知の不良クラスタ。要求される場合、ここで、ボリュームスキャンからの不良クラスタのリスト
・使用可能なＵｐｃａｓｅテーブル
・使用可能な属性定義テーブル
初期ＭＦＴスキャン
ＮＴＦＳが、マッピングペアによって記述されるＭＦＴレコード全体をスキャンする。ＮＴＦＳがどれだけの情報をメモリの中に保持することができるかという限界に起因して、数回の走査を行う必要がある可能性がある。最初のスキャンが、各ファイルレコードに関する詳細な作業を行う。後続のスキャンは、必要とされるタイプの情報に関係のあるデータを探して、各ＭＦＴを順に調べるだけでよい。この段階の終了時に、以下が真でなければならない。すなわち、
・ＭＦＴビットマップが、ＭＦＴの中のファイルレコードの状態に対応することを確認する。これは、すべてのＩＮ−ＵＳＥファイルレコードがＭＦＴビットマップの中で設定され、壊れている可能性がある要求されたシステムファイルレコードに関するビットも同様である。これは、ＭＦＴビットマップのサイズに依存して、複数回のスキャンで行われる必要がある可能性がある。

・インデックス付きの属性の数のカウント。これには、ファイル名属性、再解析属性、およびオブジェクトＩＤ属性が含まれる。これは、オーファンをチェックする場合、後に使用される。

・すべての属性の内容が、その時点で調べられていない可能性があるが、ＩＮ−ＵＳＥというマークが付けられたすべてのファイルレコードが、正しく構築されている。

・ベースファイルレコードと子ファイルレコードが、正しく構築された属性リストを介して接続される。

・ユーザファイルおよびディレクトリが、名前のないデータストリームまたはファイル名インデックスを含む。０の長さのストリームまたはインデックスをそこに挿入する必要がある可能性がある。

・属性の内容がまだ正しくない可能性があるが、システムファイルが、基本的な要求される属性を含む。そのシステムファイルに関する無効な属性が、存在する場合（すなわち、ＭＥＴがＥＡを有さない）、削除される。

・内部データが完全に確認されていない場合でも、要求されるシステムファイルが存在する。

・ファイルに内部で矛盾がない。これは、ＤＯＳスタイルのファイル属性が、個々の属性上のＮＴＦＳ属性ビットと合致することを意味する。ＥＡビットおよび再解析ビットが、それらの属性の内容と合致し、ＥＡとＥＡ−ＩＮＦＯＲＭＡＴＩＯＮに矛盾がない。

・また、複数のファイル名属性が存在する場合、それらの属性が、同一のディレクトリに対する複数の合致するエントリでないことを確認する。

・割り当てられたクラスタの正確なスナップショットが、ボリュームビットマップの中で反映される。これは、完全なビットマップの部分範囲（ｓｕｂｒａｎｇｅ）に過ぎない可能性がある。ビットマップ全体を再構築するのにＭＦＴ全体の数回の走査を要する可能性がある。

・クロスリンクが見つけられ、修復される。属性に割り当てられた新たなクラスタが、他のストリームに割り当てられたクラスタとともに見つかる。

インデックス修復スキャン
これは、ＩＮＤＥＸビットが設定されたベースファイルレコードを探してＭＦＴを順に調べることに関わる。次に、インデックスが検証される。このスキャンの終了時に、以下が真でなければならない。すなわち、
・インデックスが正しく並べ替えられている。

・インデックスエントリが正しい形式である。無効なエントリが削除され、オーファンスキャンで見つかるものと予期される。

・インデックスバッファが正しい形式である。

・残りのインデックスエントリに関する対応する属性が存在することが保証される。

・初期段階中に見つかったインデックス付き属性のカウントが、エントリが検証されるたびに減分される。現在のカウントは、対応するエントリがまだ見つかっていない属性の数を反映する。

・インデックスに関する＄ＩＮＤＥＸ−ＲＯＯＴが、正しい照合順序規則および既定サイズを有する。

・＄ＢＩＴＭＡＰおよび＄ＩＮＤＥＸ−ＡＬＬＯＣＡＴＩＯＮが、実際に使用されているバケットを反映する。

オーファンスキャン
ＮＴＦＳが、前述の完全なボリュームスキャンを行っている際、インデックス付き属性のカウントを保持する。インデックスが検証されるにつれ、インデックスの中で個々のエントリが見つかると、カウントが減分される。ユーザが、そのシステム上でアクティブであり、インデックスにエントリを追加する場合、グローバルインデックスカウントに正しくバイアスがかけられる必要があることに留意されたい。完全なインデックススキャンは、インデックスを探してＭＦＴを順次に調べる。これは、ＮＴＦＳが、すべてのインデックスエントリが検証済みである時点を保持することができることを意味する。ユーザが、ＭＦＴの中でより早期にディレクトリを変更する場合、インデックスカウントは、更新を必要としない。ユーザが、その時点より後にディレクトリの中のエントリを変更する場合、インデックスカウントは、行われている操作に応じて、増分される、または減分される必要がある。

このスキャンは、前述の最初の２回のスキャンの後、未解決のインデックス付き属性が残っている場合にだけ、必要とされる。このスキャンは、ＭＦＴを再び順に調べ、インデックス付き属性を探すことに関わる。見つかった各エントリについて、ＮＴＦＳは、関係のあるインデックスの中を調べ、対応するインデックスエントリが存在することを確認する。このスキャンは、ＮＴＦＳが合致する数のオーファンを見つけた時点で級に終わらせることができる。

システム上でアクティブなユーザが、オーファンを見つける可能性もある。ファイル削除動作中、例えば、ＮＴＦＳが、対応するインデックスエントリを有さない属性を見つける可能性がある。完全なボリュームスキャンが行われている場合、孤立した属性が削除され、ボリュームスキャンによって保持されるインデックス付き属性のカウントが減分されることが可能である。

ＮＴＦＳは、そのリリースのバージョン番号を上げる（ｂｕｍｐ）。下位互換性のあるＮＴＦＳが、ＷｉｎＸＰ（商標）システムのＳｅｒｖｉｃｅ Ｐａｃｋアップグレードとして提供される。下位互換性のあるＮＴＦＳは、バージョンアップグレードに起因する変更をサポートし、ＷｉｎＸＰ（商標）システム上で起動された場合にボリュームが整合性を有するように保つ。そのリリースのディスク上のバージョンに対する変更には、以下が含まれる。すなわち、
ボリュームＤＡＳＤファイルレコードの中に格納された新たなバージョン番号。

・ファイルレコードヘッダの中にファイルレコード番号を含めるようにすべてのファイルレコードを更新しようと試みるように行われる初期スキャン。属性リスト制約、またはディスク空間の欠如により、一部のボリュームに関してこれが不可能になる可能性がある。ボリュームＤＡＳＤファイルレコードの中のフラグにより、スキャンが完了したことが示される。

・やはりボリュームＤＡＳＤファイルレコードの中に格納され、すべてのファイルレコードのヘッダの中にも格納される、ボリュームに関連する固有識別子。これにより、ＭＦＴレコードに関する完全なボリュームスキャンが、所与のボリュームに属するレコードを正しく探し出すことが可能になる。これにより、レコードが、別のボリュームのディスクイメージであるか、またはボリューム上のファイル内に含まれる別のボリュームのスナップショットである可能性があるケースに対処が行われる。ボリュームＤＡＳＤファイルレコードが失われた場合、ＮＴＦＳは、ＭＦＴ自体に関するファイルレコードが、独自のマッピング情報を有することに注目することにより、矛盾を解決しようと試みることができる。ボリューム上に複数のＭＦＴファイルイメージが存在する場合、独自のマッピングによれば、それらの１つだけが、正しく配置されている可能性が高い。

・可能な場合、ＭＦＴの最初の０ｘ１０レコードを範囲に含むようにＭＦＴミラーを拡張する。

・バージョン番号が既知のバージョン番号を超えている場合、Ｃｈｋｄｓｋ（オフラインおよびオンライン）は、ディスク上の属性定義テーブルを遵守する。通常、これは、マイナーバージョン番号がメジャー番号として進められることが稀であることを意味する。

・ボリュームをマウントした前回のシステムのバージョン番号が、ボリュームＤＡＳＤレコードの中に格納される。

・新たなセキュリティ記述子を使用するようにすべてのシステムファイルを更新する
ＣｈｋＤｓｋ関連のＦｓｃｔｒｌ
現在の修復が終了するのを待つ
現在の修復は何であるか
現在の修復はどのぐらい進んでいるか
現在の修復を強制終了する
現在の修復および保留中の修復を強制終了する
スキャンを開始する（いずれのレベルのスキャンか、ＲＯまたはＷ）
ＣｈｋＤｓｋ関連ステータスコード
修復が行われているために動作が失敗した
破損が検出されたために動作が失敗した
ファイルを修復することにより、現在のハンドルが無効化されることが生じたために動作が失敗した
長期スキャンが実行されている間にＳＴＡＴＵＳ−ＣＯＲＲＵＰＴが戻されるが、スキャンの終了時にユーザのハンドルが有効である（可能性として）一時的なエラーと、見つかったエラー、およびその後の修復に起因してユーザのハンドルが決して有効にならないことを示すＳＴＡＴＵＳ−ＣＯＲＲＵＰＴの区別をすることが重要である可能性がある。

レジストリ設定
破損を報告するが、ユーザが開始するまでオンラインＣｈｋＤｓｋを実行しない。このようにして、依然として存在するいずれの有効なファイル／ディレクトリ上でもシステムダウンタイムが存在しない。

修復処理を実行するスレッド
ＮＴＦＳは、修復処理を実行する専用のワーカースレッド（ｗｏｒｋｅｒ ｔｈｒｅａｄ）を開始させる（ｆｉｒｅ ｏｆｆ）。これは、ＮＴＦＳが、修復作業項目を有するＩｒｐＣｏｎｔｅｘｔを整理した時点の後に行われる。スレッドは、クリティカルなワーカーキューによって使用されるＥｘＷｏｒｋｅｒスレッドと同一の優先順位で実行される。ＮＴＦＳは、スレッドが既にスケジュール済みであるか、または実行されているかどうかを確認してから、新たなスレッドをスケジュールする。

ワーカースレッドをスケジュールすることが失敗した場合、ＮＴＦＳは、作業項目をキューに入れているが、スレッドはまったく実行していない。ＮＴＦＳは、修復スレッドをスケジュールすることに成功した後、ＮｔｆｓＤａｔａフラグを設定する。ＮＴＦＳは、作業項目が存在するが、修復スレッドがまったく実行されていないことを検出した場合、それぞれのあいまいなチェックポイント間隔中に、スレッドをスケジュールしようと試みることを続ける。

ＮＴＦＳは、グローバル作業キューに入れられた修復項目のカウントを使用して、ワーカースレッドがスケジュールされる必要があるかどうかを判定する。この値は、作業項目がキューに入れられる前に増分され、作業項目が完了した後に減分される。０から１への遷移は、スレッドが、値を増分したスレッドによって開始されるべきことを示す。１から０への遷移は、現行の修復スレッドが存在することが可能であることを示す。値を調整し、以前の状態を試験するインタロックされた（ｉｎｔｅｒｌｏｃｋｅｄ）動作を使用して、メッセージスレッド変更を特定することができる。

ＮｔｆｓＤａｔａ待ちの修復キュー（ＮｔｆｓＤａｔａ Ｐｅｎｄｉｎｇ Ｒｅｐａｉｒ Ｑｕｅｕｅ）
ＮＴＦＳは、キューを使用して新たな作業項目をポスティングし、保留中の作業を編成する。

第１に、キューは、作業項目が最初にポスティングされる場所である。それらの作業項目は、見つかった破損を記述し、場合により、行われるべき修復作業のタイプのヒントを記述する。作業項目は、破損が、いつ検出され、ポスティングされたかに基づいて順序付けられる。作業項目の中には、破損がいつ検出されたかを示す順序番号も存在する。作業項目は、最初、そのキューの先頭に入れられる。

キューの第２の用途は、他の何らかの動作が終了するまでブロックされる修復処理を保持することである。他の何らかの修復を待ってブロックされる作業項目は、キューの末尾に入れられる。ブロックされる作業項目の中には、その新たな修復が最初の作業項目のすべての破損を修正する場合、まず完了されるべき新たな作業項目への参照も存在する。例として、ファイルを検証しており、属性リストが壊れており、失われていることを見出したものと想定する。ファイル修復は、所与のファイルに属するすべてのファイルレコードを探す完全なＭＦＴスキャンが行われるまで、延期される必要がある。最初の作業項目は、依存する修復が実行される間、作業リストのキューに再び入れられる。

作業項目が完了すると、ＮＴＦＳ修復スレッドは、完了されたばかりの修復の副作用として完了することができる項目を探して、作業キュー全体を調べる。これは、完了されたばかりの作業項目を参照するエントリを探してリストを走査する（ｔｒａｖｅｒｓｅ）ことによって行われる。このスキャン中、ＮＴＦＳは、修復されたばかりの同一のオブジェクトの中で検出された他の破損も探し、関連する作業項目も完了させる。ファイルに対する修復が行われている間、ファイルの別の属性に独立の破損が見つかったものと想定されたい。ファイル検証が完了すると、すべての属性が正しいことが真でなければならない。ファイル上で別の作業項目を開始する理由はまったくない。ＮＴＦＳは、修復項目に関連付けられた順序番号を使用して、ファイル修復が完了した後に新たな破損が見つかっているかどうかを判定する。

修復同期の終了
作業項目が完了すると、その作業項目の中のイベントが、存在する場合、シグナルされる（ｓｉｇｎａｌｅｄ）。イベントをシグナルした後、修復スレッドは、作業項目の中の参照カウントを減分し、カウントが０に遷移した場合、その作業項目を削除する。イベントを待っているユーザスレッドも、作業項目の中の参照カウントを減分する。カウントがその時点で０になった場合、作業項目を削除することを担うのは、ユーザスレッドである。

ユーザＩＲＰまたはユーザスレッドをキャンセルする
実行されることが可能になるにはまず、修復処理が完了するのを待たなければならないユーザスレッドが、存在することが可能である。ＮＴＦＳ最上レベルで、作業項目の中の通知イベントを介して修復処理を待つことができる。ＮＴＦＳは、ユーザが、スレッド、または現行のＩＲＰをキャンセルすることができるように、カーネルモードＡＰＣをブロックせずに、待たなければならない。イベントを待つ間に戻されたステータスコードにより、システムが現行のスレッドを強制終了していることが示された場合、ＮＴＦＳは、ＳＴＡＴＵＳ−ＦＩＬＥ−ＣＯＲＲＵＰＴ−ＥＲＲＯＲで現行のＩＲＰを完了させることができる。ＮＴＦＳは、キャンセルＩＲＰと同期する戦略を使用する。ＮＴＦＳは、修復作業項目上の参照カウントを減分し、カウントが０になった場合、その項目を削除することもできる。

ＮＴＦＳは、修復処理が行われている間に保持されている任意のＩＲＰがキャンセルされることも可能にする。ＮＴＦＳは、ＩｒｐＳｐ．Ｉｎｆｏｒｍａｔｉｏｎフィールドを使用して、そのＩＲＰに対してキャンセルを受け取ったことを示し、作業項目通知イベントを待つ時点ではなく、キャンセルルーチンにおいてＩＲＰを完了させる。

修復作業をキャンセルする
自己回復ＮＴＦＳは、任意の修復を細かく行う。ＮＴＦＳは、長い期間にわたってリソースを保持することにより、システムにおける大幅なタイムアウトを生じさせることを望まない。ＮＴＦＳは、現行の作業項目とともに状態情報を保持し、次にどのような作業を行うべきかを知っている。作業の各クォンタム（ｑｕａｎｔｕｍ）の始めに、ＮＴＦＳは、現行の作業項目がキャンセルされるべきかどうかをユーザが示したかどうか、または修復されているボリュームがマウント解除されているかどうかを確認する。これらのいずれかが該当する場合、修復スレッドは、現行の修復、ならびに示された他のあらゆる修復をアボートする。次に、ＮＴＦＳは、各作業項目を処理し、修復に関連するＩＲＰを完了させるとともに通知イベントをシグナルする。

実行中のシステムにおける破損検出
破損が検出された時点で、ＮＴＦＳは、修復作業項目を割り当て、破損の詳細でその作業項目を初期設定する。作業項目は、最上レベルのＩｒｐＣｏｎｔｅｘｔに付加される。これは、スレッドスタックコンテキストのチェーンを順に上って調べることを要する可能性がある。これが行われるのは、修復が、ユーザのために発行されたＩｒｐに関連付けられる必要がある可能性があるからである。入出力スタックは、最上レベルの要求が発行されたポイントまで戻る必要がある。破損が検出されると、ＮＴＦＳは、その破損に関してポスティングされた作業項目が既に存在するかどうかをチェックする必要がある。これは、破損に関わるＦＣＢまたはＳＣＢの状態をともに調べて、その破損を範囲に含む作業項目が既にポスティングされているかどうかを確かめることを意味する。

修復作業項目
ＮＴＦＳは、ＩＮＳＵＦＦＩＣＩＥＮＴ−ＲＥＳＯＵＲＣＥＳに起因して割り当てが失敗したケースを扱う少数の作業項目をグローバルリスト上に保持する。作業項目は、構造内に以下のフィールドを有することが可能である。

ＮｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔ−その修復作業が完了したことを待ちスレッド（waiting thread）にシグナルするのに使用される。

ＲｅｆｅｒｅｎｃｅＣｏｕｎｔ−その作業項目が依然として存在している理由の数を示す。この値は、最初、１または２に設定される。一方の参照は、ワーカースレッドによって行われるべき修復に起因する。他方の参照は、作業項目が完了されるのを待つスレッドが存在する場合、設定される。ワーカースレッドは、前述のＮｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔをシグナルした後、参照カウントを減分する。待ちスレッドは、存在する場合、待ちスレッドが修復をもはや待っていない（修復が完了したか、または待ちスレッドがキャンセルされた）時点で、この参照を減分する。いずれのスレッドであれ、参照カウントを０に遷移させたスレッドが、作業項目を削除することを担う。

ＦｉｌｅＲｅｆｅｒｅｎｃｅ−これは、いずれのファイルが実際に壊れているかを示す。ＭＡＸＵＬＯＮＧＬＯＮＧの値により、それが、ファイル破損が修復されているのではないことが示される。値が、ＭＡＸＵＬＯＮＧＬＯＮＧではない場合、そのファイルに関するＦＣＢは、そのファイルがメモリを離れることを防止する参照を有する。

ＦｉｌｅＲｅｃｏｒｄＲｅｆｅｒｅｎｃｅ−これは、いずれのファイルレコードが実際に壊れているかを示す。ＭＡＸＵＬＯＮＧＬＯＮＧの値により、既知の壊れたファイルレコードが存在しないことが示される。

ＡｔｔｒｉｂｕｔｅＯｆｆｓｅｔ−そのオフセットを超えると壊れているＦｉｌｅＲｅｃｏｒｄにおけるオフセットである。０の値は、既知の壊れた属性がまったく存在しないことを示す。ただし、０の値は、確認される必要がある属性が存在しないことは意味しない。例えば、ＮＴＦＳが、ある属性が欠落していることを検出している。

ＡｔｔｒｉｂｕｔｅＴｙｐｅＣｏｄｅ−確認される必要がある属性タイプコードを示す。

ＡｔｔｒｉｂｕｔｅＮａｍｅ−確認される必要がある属性の名前のＵＮＩＣＯＤＥ文字列。

ＮＴＳＴＡＴＵＳ−修復が正常に完了したかどうかを示すステータス。

ＩＲＰ−これは、修復処理を開始するようにユーザによって発行されたＩＲＰである。これは、破損が検出された時点で処理されていたＩＲＰであることも可能である。以下のＦｌａｇｓフィールドの中の情報により、その場合がどちらのケースに該当するかが示される。第１のケースでは、ＩＲＰは、修復が完了した後、完了される。第２のケースでは、ＩＲＰは、修復が完了した後、再試行される。この第２のケースが利用されるのは、ＮＴＦＳが、ＳＴＡＴＵＳ ＰＥＮＤＩＮＧをユーザに既に戻している場合だけであり、その場合、ＩＲＰは、ＥｘＷｏｒｋｅｒＴｈｒｅａｄにポスティングされなければならない。ＮＴＦＳは、キャンセルＩＲＰスピンロック（ｓｐｉｎｌｏｃｋ）を使用してシリアル化し、それがユーザアクションによってキャンセルされていないという条件付きで、これを完了させる。

Ｆｌａｇｓ−行われるべき修復についてさらなる詳細を示す。ＩＲＰ（存在する場合）が、通知のためであるか、または再発行されるべきであるかどうかも示す。通知Ｉｒｐは、スキャンを開始するためにユーザによって発行される。

ＬＩＳＴ−ＥＮＴＲＹ−作業項目のグローバルキュー。

ＲｅｌａｔｅｄＷｏｒｋＩｔｅｍ−存在する場合、ＲｅｌａｔｅｄＷｏｒｋＩｔｅｍが完了した後、その作業項目を完了することができることを示す。ＲｅｌａｔｅｄＷｏｒｋＩｔｅｍは、その作業項目を処理している間に見つかった破損の結果として作成される。

ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ−その作業項目に関連する番号。見つかった破損が、修復が完了した後に検出されたかどうか日付を入れる（ｄａｔｅｌｉｎｅ）のに使用される。

致命的ではない破損
一部のケースでは、ＮＴＦＳは、破損を検出するが、修復が完了するまで現行の要求の完了を延期する必要がない。その場合、ＮＴＦＳは、最上レベルにポスティングされるべき作業項目を生成するが、現行の要求を処理することを続けることができる。修復が行われている最中に破損を回避する戦略が存在する場合が、これに当てはまる。回避をインラインで開始することができる場合、現行の要求は、作業項目を最上レベルのＩＲＰ−ＣＯＮＴＥＸＴに付加した後に続けられることが可能である。この場合の例が、壊れたセキュリティ記述子である。修復項目は、生成されることが可能であるが、現行の要求は、修復が完了するまで現行のファイルに関するＳＹＳＴＥＭ／ＡＤＭＩＮ記述子を使用する。

同じ場所における修復（Ｉｎ−Ｐｌａｃｅ Ｒｅｐａｉｒ）
一部の修復は、最上レベルのスレッドに作業項目をポスティングすることを要さない。一部の修復は、現在、実行中の動作内で行われることが可能である。例えば、ＮＴＦＳが、ボリューム＄ＢＩＴＭＡＰ内のビットを解放しており、そのビットが既にクリアであることを見出した場合、作業をポスティングする必要がまったくない。自己回復ＮＴＦＳの初期バージョンは、最適化よりも単純なモデルを優先し、したがって、修復がインラインで行われることが可能である場合でも、ポスティングすることを選択する可能性がある。

ユーザが開始した修復
ＮＴＦＳは、実際の作業を行うようにワーカースレッドのキューに入れられる作業項目を生成する。この場合、ユーザ要求およびユーザスレッドは、修復処理と対話する普通のユーザ要求の場合と同一の待ち技術を使用する。

ＦｉｌｅＩＤハンドルによるオープン
開いたファイルに対するすべてのハンドル（およびＣＣＢ）を見つけるため、ＦｉｌｅＩＤまたはＯｂｊｅｃｔＩＤによって開かれたファイルも見つける必要がある。ＣＣＢは、オープンをサポートするＳＣＢのキューから出される（ｑｕｅｕｅｄ ｏｆｆ ｏｆ）。ＮＴＦＳは、無効にされるべきＣＣＢを探して、特定のストリーム、または特定のファイルに関するストリームのすべてについてＣＣＢを順に調べる。

試験における考慮すべき事項（Ｔｅｓｔｉｎｇ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ）
・どのように破損をオンラインで生成するか
・どのように修復を検証するか
・どのようにＮｔｆｓを呼び起こして（ｐｒｏｖｏｋｅ）破損を検出させるか
・Ｕｓｎ通知およびＤｉｒＮｏｔｉｆｙ通知を確認する
・Ｆｓｃｔｌを確認する
・修復後のハンドル挙動を確認する
・ブート破損を生成する
・修復が実行されている間の待ち動作およびキャンセル動作を確認する
・修復がまったく行われないが、スキャン中に見つかった破損が報告される場合に試験を行うための可能な修復モード。これは、ＮＴＦＳが破損を探していることを確認するように試験を行うための機会を与える。

同時実行の修復処理
ＮＴＦＳは、別個のスレッドにおいて同時に破損を検出することができる。自己回復ＮＴＦＳの初期バージョンは、修復を単一の作業キューにポスティングし、必要に応じて生成された専用のスレッド内で修復を処理する。自己回復ＮＴＦＳの将来のバージョンは、それらの修復処理が、別個のスレッド内で、具体的には、破損が検出された時点でユーザのために実行されているスレッド内で実行されることを可能にすることができる。この戦略は、限られたスコープを有する修復にだけ適切である。ユーザは、自分の要求をキャンセルする、またはアプリケーションに関連するスレッドを強制終了する可能性があるが、修復処理は、実際に完了まで実行される必要があるため、長期実行修復処理は、専用スレッドにポスティングすることが賢明である。

修復作業キューおよび作業項目を処理するルーチンは、何らかの将来のバージョンにおいて同時実行の修復を可能にする意図をもって設計される。

破損のタイプおよび関連する修復ファイル属性
属性が欠落している。

属性リストが壊れている。

属性オフセットが範囲外である。

属性レコード長＝０である。

属性テーブルが壊れているか
属性ＶＣＮが負である。

属性＞ＲｅｃｏｒｄＬｅｎｇｔｈ＝０である。

ＡｔｔｒｉｂｕｔｅＬｉｓｔが壊れている。

壊れた属性：不良なＶＣＮ範囲、ルックアップされるべきｖｃｎが範囲外である。

壊れたファイル名属性、ファイル名リンクが不良である、またはディレクトリに＄ＩＮＤＥＸ−ＲＯＯＴが欠けている。

ＦＩＬＥ−ＡＴＴＲＩＢＵＴＥ−ＲＥＰＡＲＳＥ−ＰＯＩＮＴフラグが設定されていない。

ファイル名属性が欠落している。

インデックス付き属性が既に存在する。

ＩｎｄｅｘＥｎｔｒｙが無効である（壊れた属性）。

ＭＦＴデータ属性が欠落している。

オープン属性テーブル内でエントリが欠落している。

インデックス付きでない属性が既に存在する。

非常駐＄ＤＡＴＡ属性が欠落している。

非常駐属性が既に存在する。

常駐属性データがレコード長を超えた。

＄ＳＴＡＮＤＡＲＤ−ＩＮＦＯＲＭＡＴＩＯＮ属性が欠落している。

割り当て
ファイルレコードに割り当てが十分でない。

割り当ての破損
割り当てを見つけることができなかった。

ＶＣＮが不良である。

ＶＣＮが大き過ぎる。

０のＬＣＮ
割り当てを超えてデータにアクセスしようとしている。

ＬＣＮ０を空きに設定しようとしている。

ＬＣＮが使用中である。

非常駐ＡｌｌｏｃａｔｅｄＬｅｎｇｔｈが大き過ぎる。

インデックス
壊れたインデックスツリー
インデックスエントリを見つけることができなかった。空のインデックス。

空のインデックスエントリリーフ。

インデックスバッファが壊れている。

インデックスエントリが既に存在する。

インデックスエントリが存在しない。

インデックスエントリが壊れている。

名前インデックスが無効である。

レコードインデックスが大き過ぎる。

レコードが、再解析ポイントインデックス内で見つからない。

０の長さのインデックスエントリ長。

ＵｐＣａｓｅテーブル
Ｕｐｃａｓｅテーブルが大き過ぎる。

Ｕｐｃａｓｅテーブルにアクセスすることができなかった。

ログファイル
無効なログレコード。ログファイルがいっぱいである。

再起動
無効な再起動インデックス。

無効な再起動テーブル。

未割り当ての再起動テーブルエントリ。

セキュリティ
壊れたセキュリティｉｄ。

ファイル破損
ファイルレコード破損。

ＦＩＬＥ署名が壊れている。

Ｆｉｌｅｓｉｚｅが割り当てより大きい。

Ｆｉｌｅｓｉｚｅが再解析ポイントには大き過ぎる。

不良なファイルレコードか。

無効なＦｉｌｅＳｉｚｅ、ＶａｌｉｄＤａｔａＬｅｎｇｔｈ、またはＡｌｌｏｃａｔｉｏｎＳｉｚｅ。

非常駐ＦｉｌｅＳｉｚｅが再解析ポイントには大き過ぎる。

未割り当て範囲を有する非散在（ｎｏｎ−ｓｐａｒｓｅ）ファイル
ＦＲＳサイズを超えるＲｅｃｏｒｄＯｆｆｓｅｔ。

ファイルは、０のＶｃｎ変更バイト、または８を超えるＶｃｎ変更バイト、８を超えるＬｃｎ変更バイトが存在する場合、あるいはレコードの終端を越える（ｗａｌｋ ｏｆｆ）場合、またはＶｃｎ変更が負である場合、壊れている。

ＭＣＢが存在しない。

ＭＣＢが壊れている。

予期しなかったファイル参照。

アボートの失敗（Ｆａｉｌｅｄ ａｂｏｒｔ）
排他的ＦＣＢリスト（およびビットマップフラグ）を順に調べて、何を修復する必要があるかを特定する。

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

本発明を適用できる実施形態の実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するのに適した典型的なコンピューティング環境を示す図である。 本発明を適用できる実施形態の実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するために構成されたコンピュータの典型的な実施形態を示す図である。 本発明を適用できる実施形態の実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するための典型的な方法を示す流れ図である。 本発明を適用できる実施形態の実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するための典型的な方法を示す流れ図である。 本発明を適用できる実施形態の実行中のボリューム上で検出された破損のリアルタイムなオンライン修復を可能にする拡張されたファイルシステムを実装するための典型的な方法を示す流れ図である。

符号の説明

１０２ コンピュータ
２００ プロセッサ
２０２ オペレーティングシステム
２０４ アプリケーションプログラム群
２０６ メモリ
２０８ ファイルシステム
２１０ ハードディスク
２１２ リアルタイム修復モジュール

Claims (20)

1. コンピューティングデバイス内のファイルシステムを使用して、ストレージボリューム内のデータを修復する方法であって、
   前記ストレージボリューム上でデータの破損を検出するステップと、
   ここで、前記破損は、ファイルシステム要求に関連する破損、ユーザオペレーションに関連する破損、前回の修復により無効にされたハンドルに関連する破損のいずれかであり、
   前記破損の修復中に前記ストレージボリュームがオンラインで、アクティブなままであるように、前記破損をリアルタイムで修復するステップと、
   ここで、前記修復するステップは、
   前記検出された破損が前記ファイルシステム要求に関連する場合、該検出された破損に対応する修復スキャンを定義するステップと、
   前記検出された破損が前記ユーザオペレーションに関連する場合、該検出された破損に対応する修復スキャンを定義するステップとを含み、
   前記修復スキャンを実施するステップと
   を具えたことを特徴とする方法。
2. 前記修復するステップは、
   前記修復スキャンが完了すると、前記ファイルシステム要求の実行を再開するステップと
   をさらに含むことを特徴とする請求項１記載の方法。
3. 前記破損が検出された時点で前記破損を記述する情報を記録するステップであって、前記修復スキャンは、該情報に基づいて定義されるステップと
   前記破損が検出されたことを示すエラーステータスを発生させるステップと、
   前記破損の存在を示すエラーステータスに応答して、前記ファイルシステム要求の実行を中断するステップと
   をさらに具えたことを特徴とする請求項２記載の方法。
4. 前記修復スキャンを定義するステップは、前記検出された破損に基づいて、より低いレベルのスキャンの集合を含む複合修復スキャンを定義するステップを含むことを特徴とする請求項１記載の方法。
5. 前記修復スキャンを実施するステップは、前記複合修復スキャンに含まれるより低いレベルのスキャンを実施するステップを含むことを特徴とする請求項４記載の方法。
6. 前記修復スキャンを実施するステップは、現行のスレッド内の最上レベルの実行ポイントで修復ルーチンを実行して、前記修復スキャンを実行するステップを含むことを特徴とする請求項１記載の方法。
7. 前記ファイルシステム要求の実行を再開するステップは、
   前記修復スキャンが完了していない場合、前記ファイルシステム要求を拒否するステップと、
   前記修復スキャンが完了していないことを示す破損ステータスエラーを発行するステップと
   を含むことを特徴とする請求項２記載の方法。
8. 前記ファイルシステム要求は、再帰的な要求であり、
   前記再帰的な要求の最上レベルの要求まで戻るステップと、
   前記最上レベルの要求に関して前記修復スキャンを実施するステップと
   をさらに具えたことを特徴とする請求項１記載の方法。
9. 前記修復スキャンは、属性スキャンと、ファイルスキャンと、インデックススキャンと、
   ボリュームビットマップ再構築と、セキュリティ記述子ファイルスキャンとを含むグループから選択されることを特徴とする請求項１記載の方法。
10. 前記修復スキャンを受けるファイルに関連する第２のファイルシステム要求を受け取るステップと、
    前記修復スキャンが長期実行修復である場合、前記第２のファイルシステム要求を拒否するステップと、
    前記修復スキャンが短期実行修復である場合、前記修復スキャンが完了するまで前記第２のファイルシステム要求を延期するステップと
    をさらに具えたことを特徴とする請求項１記載の方法。
11. 前記修復スキャンを実行しないように前記修復スキャンを無効にするファイルシステム制御コマンドを受け取るステップと、
    前記修復スキャンが長期実行修復である場合、前記修復スキャンを無効にするステップと
    をさらに具えたことを特徴とする請求項１記載の方法。
12. 前記修復スキャンを実施している最中にさらなる破損を検出するステップと、
    前記さらなる破損のための新たな修復スキャンが完了するまで前記修復スキャンを延期するステップと
    をさらに具えたことを特徴とする請求項１記載の方法。
13. 前記修復スキャンを実施している最中に、前記コンピューティングデバイスの断続的なハードウェアエラーを検出するステップと、
    前記断続的なハードウェアエラーが検出された場合、前記修復スキャンを拒否するステップと、
    前記拒否された修復スキャンをイベントログに記録するステップと
    をさらに具えたことを特徴とする請求項１記載の方法。
14. 前記修復スキャン中にファイルシステムメタデータに対して検証スキャンを開始するステップをさらに具えたことを特徴とする請求項１記載の方法。
15. 前記検証スキャンを開始するステップは、完全なボリュームスキャンと、セキュリティスキャンと、ファイルスキャンと、ストリームスキャンと、ディレクトリスキャンと、ビューインデックススキャンとを含むグループから選択された検証スキャンを開始するステップを含むことを特徴とする請求項１４記載の方法。
16. 前記ファイルシステムを用いて、前記破損したデータを検出したとき、リアルタイム修復モジュールを呼び出すステップと、
    前記ファイルシステム内部に組み込まれたリアルタイム修復モジュールを用いて、前記ファイルシステムからの前記呼び出しに応答して、前記破損したデータを修復するステップと
    を具えたことを特徴とする請求項１記載の方法。
17. コンピュータに、請求項１ないし１６のいずれかに記載の方法を実行させることが可能な命令を有するコンピュータプログラム。
18. 請求項１７記載のコンピュータプログラムを有するコンピュータ読取り可能な記録媒体。
19. １つまたは複数のストレージボリュームが構成されたハードディスクと、
    前記ストレージボリューム上の壊れたデータのリアルタイムな修復を、該ストレージボリュームがオンラインのままでありながら実行するように構成されたファイルシステムと
    を具え、該ファイルシステムは、
    前記ストレージボリューム上でデータの破損を検出する手段と、
    ここで、前記破損は、ファイルシステム要求に関連する破損、ユーザオペレーションに関連する破損、前回の修復により無効にされたハンドルに関連する破損のいずれかであり、
    前記破損の修復中に前記ストレージボリュームがオンラインで、アクティブなままであるように、前記破損をリアルタイムで修復する手段と、
    ここで、前記修復する手段は、
    前記検出された破損が前記ファイルシステム要求に関連する場合、該検出された破損に対応する修復スキャンを定義する手段と、
    前記検出された破損が前記ユーザオペレーションに関連する場合、該検出された破損に対応する修復スキャンを定義する手段とを含み、
    前記修復スキャンを実施する手段と
    を具えたことを特徴とするコンピューティングデバイス。
20. 前記ファイルシステム内部に組み込まれたリアルタイム修復モジュールをさらに具え、
    前記ファイルシステムは、前記壊れたデータを検出したとき、前記リアルタイム修復モジュールを呼び出す手段を含み、
    前記リアルタイム修復モジュールは、前記ファイルシステムからの前記呼び出しに応答して、前記破損したデータを修復する手段を含むことを特徴とする請求項１９記載のコンピューティングデバイス。

Images