Windows Info 第391回

WindowsのNTFS／ReFSに搭載されている「再解析ポイント」とは何か？

そもそも「再解析ポイント」（Reparse Point）とは何か

　「再解析ポイント」について、本連載でも何度扱ってきたが、これ自体をしっかり紹介していなかった。今回はあらためて詳しく解説しよう。

　再解析ポイントとは、「Reparse Point」のMicrosoftによる公式な日本語訳だ。原語を日本語読みした「リパース・ポイント」という表記もインターネット上では散見されるが、Microsoftのサイトでは、コミュニティページへのユーザーの書き込みか、自動翻訳のページでしか見つからない。しっかり翻訳していた頃のページでは、ほぼ「再解析ポイント」で統一されている。なのでここでは、この用語を使う。

　再解析ポイントは、NTFSおよびReFSに装備された、ファイルシステムの機能だ。以前にも解説したジャンクションやシンボリックリンクなどを実現するための技術として用いられている。このため、「ジャンクションは再解析ポイントである」という表記は必ずしも間違いではないが、「ジャンクション＝再解析ポイント」ではない。ジャンクションは、再解析ポイントで実現されている機能の1つである。

　しかし、再解析ポイントの用途はこれに留まらない。「アプリ実行エイリアス」やOneDriveの同期フォルダは、再解析ポイントを使って実装されている。

　再解析ポイントは、Windows 2000で初めて搭載されたNTFS 3.0で最初の実装が見られる。このとき、再解析ポイントを使った「ジャンクション」や「ボリュームマウントポイント」などの機能が利用可能になった。

　再解析ポイントと呼ばれるのは、ファイルシステムがAPIなどで指定されたパスを解析して、該当のファイルやディレクトリを探す場合の“解析”処理（Parse）が、ここで別のものに切り替わるからだ。再度（Re）解析（Parse）する地点（Point）ということでこの名称なのだ。なお、再解析ポイントは、Windowsに固有の名称であり、現状NTFSとReFSにしか搭載されていない。

　再解析ポイントは、ファイルシステムの属性の1つとして指定される。制限はあるが、ファイルにもディレクトリにも指定できる。ただし、再解析ポイントを指定する場合、ディレクトリは空でなければならず、再解析ポイントが指定されたディレクトリにサブディレクトリやファイルを置くことはできない。また、1つのパスには最大で63個までしか再解析ポイントを含めることができない。

　属性なので、ファイルの属性を取得することで、ファイルやディレクトリに再解析ポイントが指定されているかどうかを判断できる。PowerShell／Windows PowerShellならば、

Get-Item ＜パス＞ | select fullname,Attributes

で属性値（Attributes）に「RepasePoint」と表示されれば、再解析ポイントが属性として設定されている。

ディレクトリへのシンボリックリンク、ジャンクション、ファイルへのシンボリックリンクがあるとき、Get-Itemコマンドで属性を調べると、「RepasePoint」が設定されている。リンクは、すべて再解析ポイント（Reparse Point）で実現されている

再解析タグと再解析データ

　再解析ポイントが設定されると、ファイルのメタ情報として「再解析タグ」と「再解析データ」が記録される。「再解析タグ」は、再解析ポイントの「種類」を表す32bitデータである。「再解析データ」は、拡張属性と同じ場所に記録される再解析ポイント用の情報だ。

　再解析ポイントは、再解析タグから対応するファイルシステムのフィルタードライバー（あるいはミニフィルタードライバー）が、これを処理する。このため、アプリケーション側からみれば、ファイルシステムアクセスの結果として再解析ポイントの処理結果を受け取ることになり、再解析ポイントが何をしているのかを直接見ることはできず、通常のファイルのようにアクセスされる。

　現在再解析タグは、44個定義されている。定義はWindows SDKのwinnt.hにあるが、その意味は

●[MS-FSCC]Reparse Tags(英語)
　https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4?redirectedfrom=MSDN

に説明がある。多数のタグがあるが、多くはWindows Server版でのみ利用できる機能である。

　再解析タグは以下の図のような構造を持つ32bit整数データで、最上位ビットであるBit 31は、Microsoftが管理しているかどうかを示すビットで、その次のビット(Bit 30)は、予約ビットとなっていて、Microsoft以外が管理するタグでは必ずゼロにする必要がある。Bit 29、Bit 28は、「代理名」（Name Surrogate。ファイルの別名）、「ディレクトリ」（Directory。下位構造を持つ）を示し、どちらかをオンにできる（両方ともオフも可）。

再解析タグは、先頭の4ビットでタグの属性を示す。最上位ビットは、Microsoftが所有するタグであることを示すビットで、29ビットは、シンボリックリンクのようなファイルやディレクトリに対応するリンクであることを示す「Name Surrogate Bit」、28ビットは、下位構造があることを示すDirectory Bitになっている。具体的なタグの区別は下位16bitで行ない、残りのビットは予約済みビットとなっている

　再解析データは再解析タグ固有のデータで、フィルタードライバーで解釈される。標準的なデータ形式はなく、フィルタードライバーに依存するが、アプリ実行エイリアスのようにパスがUnicodeで格納されている場合もある。シンボリックリンク（再解析タグ0xa000000c）などもこのタイプで、再解析データにリンク先のパスが入る。

　再解析タグや再解析データを表示させるには、fsutil.exeコマンドを使うのが簡単だ。再解析ポイントを持つファイル、ディレクトリ（ジャンクションやシンボリックリンク、あるいはOneDriveの同期フォルダーなど）のパスに対して、

fsutil.exe reparsepoint query ＜パス＞

とする。

　以下の画面は、シンボリックリンクとジャンクションに対して、上記のコマンドを実行したもの。

シンボリックリンクやジャンクションに対して、fsutil.exeを使い、再解析ポイントの情報を表示させた。再解析ポイントには、再解析タグと再解析データが設定されていて、fsutil.exeではこれを表示させることができる

　シンボリックリンクの再解析タグは「0xa000000c」で、これはwinnt.hでは、「IO_REPARSE_TAG_SYMLINK」として定義されているタグだ。

　これに対して、ジャンクションの場合は、再解析タグは「0xa0000003」で、「IO_REPARSE_TAG_MOUNT_POINT」というタグ名を持つ。どちらも先頭4ビットのパターンが「1010」で、Microsoft BitとName Surrogate Bitがオンになっている。対象がファイルなのかディレクトリなのかは、それぞれのファイル属性値で区別できる。

　次の画面は、ユーザーフォルダにあるOneDrive同期フォルダと直下のファイルに対してfsutil.exeコマンドを実行したもの。再解析タグは「0x9000701a」で、これには「IO_REPARSE_TAG_CLOUD_7」という名前がある。ただし、「IO_REPARSE_TAG_CLOUD」で始まるタグは16個あり、環境によっては他のタグになっている可能性もある。

OneDriveの同期フォルダやその下のファイルにも再解析ポイントが設定されている。どちらも「IO_REPARSE_TAG_CLOUD」で始まる名前を持つタグで、Directory Bitがオンになっている。ファイル／ディレクトリの区別は、ファイルの属性値で判断でき、タグのDirectory Bitは下位構造を持つ可能性があるといった意味なのだと思われる

　このタグの先頭4ビットのパターンは「1001」で、Microsoft BitとDirectory Bitがオンになっている。なお、「IO_REPARSE_TAG_CLOUD」は、すべて先頭4ビットのパターンが同じで、必ずしもOneDrive上のディレクトリだけを表しているわけではない。

　たとえば、OneDriveフォルダ直下のファイルでも、再解析タグは「0x900601a」（IO_REPARSE_TAG_CLOUD_6)で、Directory Bitがオンになっていた。Directory Bitは、下位構造がありえる程度の意味なのだろう。実際にファイルなのか、ディレクトリなのかは、PowerShellのGet-Itemコマンドなどで属性を取得すれば判断できる。