Entering Passive Mode

次世代の Windows OS となる、Windows Vista や、
Longhorn Server（コードネーム）では、
いよいよ真のシンボリックリンクが登場する。

シンボリックリンクは、UNIX 系のそれとほぼ同様の機能だ。
Vista では、CreateSymbolicLink API が登場し、
OS で正式にサポートされた機能として実装される。

Vista のエクスプローラは、正式にリンクを採用したため、
昨日説明したような問題が起きないような設計になっている。
マウントポイントやシンボリックリンクを削除しても、
リンク先が削除されるようなことは起こらないのだ。

マウントポイント機能は、
使い方次第では非常に便利である。

ディスクを複数のパーティションに分けている場合、
システムドライブに空き容量が不足しても
マウントポイント機能を使えば、
ドライブにある適当なディレクトリの実体を、
別のボリュームに置くことができる。

ボリュームマウントポイントの場合は、
Windows で正式にサポートされているため、
GUI によって設定することもできるが、
別のボリューム全体がマウントされることになる。

今日はディレクトリジャンクションを作成してみる。
そのものズバリの API は存在しないので、
リパースデータバッファを自分で用意し、
DeviceIOControl を使って設定することになる。

========== 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 にアクセスしてみよう。

エクスプローラのアドレスバーや、
ファイルを開く汎用コモンダイアログでは、
拡張パス表現に対する対応をしているが、
コマンドプロンプトや「ファイルを指定して実行」は、
そのような制限がないため、入力して試すことが可能だ。

いよいよ、保留にしていたパスについて考えてみる。
GetVolumeNameForVolumeMountPoint が返却したパスは、
以下のような形式であった。

\\?\Volume{f08e7d20-64f1-11db-b10d-001125868411}\

実は、これもファイルのパス表現なのである。

最初に \\ と並んでいるので、UNC パスにも見えるが、
「?」というサーバに接続するわけではない。
では、上記のパスはどのように解釈されるのか。

昨日のもう 1 つのパスはもう少し保留しておき、
ファイルのパス表現について考えてみよう。

パソコン利用者やプログラマに単に「パス」と言えば、
こちらのファイルパス表現のことを指す。
これは、C:\～ や \\server\share\～、..\ などの、
一般的によく見る表現のことである

通常は、このパス表記を使ってファイルにアクセスする。
プログラマがファイルを利用する場合、
パスを指定してプログラミング言語固有の機構を使うが、
これは、Windows の基幹 API を呼び出す。
ファイルの場合、通常 CreateFile API である事が多い。