次世代の Windows OS となる、Windows Vista や、
Longhorn Server（コードネーム）では、
いよいよ真のシンボリックリンクが登場する。
シンボリックリンクは、UNIX 系のそれとほぼ同様の機能だ。
Vista では、CreateSymbolicLink API が登場し、
OS で正式にサポートされた機能として実装される。
Vista のエクスプローラは、正式にリンクを採用したため、
昨日説明したような問題が起きないような設計になっている。
マウントポイントやシンボリックリンクを削除しても、
リンク先が削除されるようなことは起こらないのだ。
ディスクを複数のパーティションに分けている場合、
システムドライブに空き容量が不足しても
マウントポイント機能を使えば、
ドライブにある適当なディレクトリの実体を、
別のボリュームに置くことができる。
ボリュームマウントポイントの場合は、
Windows で正式にサポートされているため、
GUI によって設定することもできるが、
別のボリューム全体がマウントされることになる。
========== part of mountpoint.c ==========
HRESULT MountPointCreate(const wchar_t *mountPointPath, const wchar_t *target) {
unsigned short pathByteLength;
char dataBuffer[MAXIMUM_REPARSE_DATA_BUFFER_SIZE];
MOUNT_POINT_INFO *info = (MOUNT_POINT_INFO *)dataBuffer;
ボリュームマウントポイントは、
ファイルシステムのディレクトリに対して、
リパースポイント機能を使うことで実現していた。
リパースポイント属性を持つディレクトリには、
リパースデータバッファという追加情報が保存されている。
リパースデータバッファには種類があるが、
ボリュームマウントポイントは、
IO_REPARSE_TAG_MOUNT_POINT という種類であり、
データとしてリンク先を表すデバイスパスが記録されていた。
サンプルとして、Windows フォルダ内にある、
win.ini にアクセスしてみよう。
エクスプローラのアドレスバーや、
ファイルを開く汎用コモンダイアログでは、
拡張パス表現に対する対応をしているが、
コマンドプロンプトや「ファイルを指定して実行」は、
そのような制限がないため、入力して試すことが可能だ。
\\?\Volume{f08e7d20-64f1-11db-b10d-001125868411}\
実は、これもファイルのパス表現なのである。
最初に \\ と並んでいるので、UNC パスにも見えるが、
「?」というサーバに接続するわけではない。
では、上記のパスはどのように解釈されるのか。
パソコン利用者やプログラマに単に「パス」と言えば、
こちらのファイルパス表現のことを指す。
これは、C:\～ や \\server\share\～、..\ などの、
一般的によく見る表現のことである
通常は、このパス表記を使ってファイルにアクセスする。
プログラマがファイルを利用する場合、
パスを指定してプログラミング言語固有の機構を使うが、
これは、Windows の基幹 API を呼び出す。
ファイルの場合、通常 CreateFile API である事が多い。
昨日、マウントポイントのバッファの内容を直接取り出したが、
そのリンク先のパスは、以下のようになっていた。
\??\Volume{f08e7d20-64f1-11db-b10d-001125868411}\
だが、これを GetVolumeNameForVolumeMountPoint で
取り出すと以下のようになる。
\\?\Volume{f08e7d20-64f1-11db-b10d-001125868411}\
一見同じに見えるが、接頭辞が異なっている。
これらはどう違い、どんな意味をもっているのだろうか。
========== 1st half of mountpoint.c ==========
#define UNICODE
#define STRICT
#define WIN32_LEAN_AND_MEAN
#define _WIN32_WINNT 0x0500
続きを読む ]]>
リパースタグなどの特殊なデータにアクセスする場合、
デバイスドライバに対して制御コードを送り、
データ構造を直接扱う必要がある。
Windows には、DeviceIoControl という API があり、
これを使うことで、デバイスドライバの制御が可能である。
リパースポイントの情報を得るためには、
対象のディレクトリハンドルに対して、
FSCTL_GET_REPARSE_POINT という制御コードを送る。
そうすれば、その結果としてリパースポイントの情報が、
リパースデータバッファと呼ばれる構造で返却される。