このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
昨日のもう 1 つのパスはもう少し保留しておき、
ファイルのパス表現について考えてみよう。
パソコン利用者やプログラマに単に「パス」と言えば、
こちらのファイルパス表現のことを指す。
これは、C:\~ や \\server\share\~、..\ などの、
一般的によく見る表現のことである
通常は、このパス表記を使ってファイルにアクセスする。
プログラマがファイルを利用する場合、
パスを指定してプログラミング言語固有の機構を使うが、
これは、Windows の基幹 API を呼び出す。
ファイルの場合、通常 CreateFile API である事が多い。
まず、これら API は受け取ったパスを正規化する。
正規化とは、相対パスからドライブつき完全パスへの変換、
メタ表現(.\ や ..\)の解決、
パス区切り記号の統一化(/ => \)、
そしてファイル名末尾のドットや空白の削除などである。
プログラマや利用者から簡単に扱えるように、
API が裏でパス文字列を解析しているのだ。
その結果、パスは完全な表現に正規化される。
例えば、「C:text.txt」は、C ドライブの
カレントディレクトリにある text.txt を指すので、
「C:\Documents and Settings\kes\test.txt」等になる。
また、\\server\share\path などの UNC は、
UNC\server\share\path というパスに正規化される。
正規化処理では、MS-DOS との互換性もあるため、
NUL や COM1 などの特殊な名前を指定すると、
それらは例え「C:\CON.txt」と指定したとしても、
パスや拡張子は無視され、「CON」に正規化される。
さて、正規化されたファイルパスは、
次にファイルシステム(フィルタ)ドライバに渡される。
ファイルシステムドライバは、正規化されたパスを受け取り、
それを「相対的なデバイスパス」として取り扱い、
昨日書いた ?? 名前空間に対して解釈する。
例えば、C:\boot.ini というパスであれば、
\??\C:\boot.ini というデバイスパスに変換される。
C: は別のデバイスを示すリンクなので、それも解決され、
\Device\HarddiskVolume1\boot.ini となる。
最終的に、このデバイスパスに基づいて、
ディスクなどの実際のデバイスにアクセスするのである。
C:\boot.ini という表現をファイルパスとしてみれば、
C: というドライブに対する \boot.ini という絶対パスだ。
つまり、ドライブ名は特別扱いされている。
しかし、デバイスにおいては「C:」はただの名前なので、
単なるデバイスの相対パスの一部となるのである。