このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
NTFS のハードリンクは、UNIX 系のそれと同じ機能である。
複数のファイル名が、同じファイルデータを指す状態だ。
それぞれのファイル名には主従関係は存在せず、
共通のデータを持つ以外、通常のファイルと変わらない。
リンクというのは、ファイルシステム内の概念であり、
NTFS ではファイル名とデータ（全ストリーム）の関係を指す。
通常のファイルは、1 つのデータに対して、
1 つのファイル名がリンクしているが、
ハードリンクされたファイルの場合、1 つのデータに対して、
複数のファイル名がリンクしているということだ。
Windows 2000 以降にはハードリンク用の API があり、
ハードリンクを作成するのは非常に簡単である。
BOOL CreateHardLink(
LPCTSTR lpFileName,
LPCTSTR lpExistingFileName,
LPSECURITY_ATTRIBUTES lpSecurityAttributes
);
まあ、今回はサンプルを書くまでもないね。
lpFileName が新しく作成するファイル名。
lpExistingFileName が元のファイル名。
もちろんこれはハードリンクでも構わない。
元のファイル名としてハードリンクされたファイルを渡すと、
さらにリンクする数が増えるということになる。
ハードリンクは、削除するために特別な遠慮はいらない。
ファイルシステムのレベルで実装されている機能なので、
上位にある OS やサブシステムでは気にする必要がないのだ。
API では DeleteFile を使ってばっさり消せるし、
エクスプローラやコマンドプロンプトでも、
通常のファイルと同じように消すことができる。
余談だが、UNIX 系ではファイルを削除するために、
unlink というシステムコールを使う。
これが、delete という名前でないのは、
古くからリンクが存在していたからで、
ファイルを消すというのは、ファイル名を消して、
データ（inode 等）へのリンクを解除することを示すからだ。
さて、ハードリンクの利便性は連載の最初に書いた。
しかし、NTFS がこの機能を搭載しているにも関わらず、
Windows NT はおろか、2000 以降になっても、
アプリケーションではほとんど利用されておらず、
Windows 自身はその機能を全く利用していない。
これには歴史的な理由がある。
アプリケーションの上書き手法によって、
ハードリンクが切れてしまう問題があるためだ。
Windows のアプリケーションは、
基本的にハードリンクのことを考慮せずに作られている。
文書をアプリケーションで開いて編集し、
それを上書きして保管する際には、
Windows に独特の処理がなされている。
アプリケーションは、上書き中のデータ消失を避けるため、
直接文書ファイルに上書きするのではなく、
まず一時ファイルを「作成」し、
元のファイルの日付情報をコピーしてから保存する。
そして、一時ファイルに正常に保存ができた場合、
元のファイルを「リネーム」し、
一時ファイルを元のファイル名に「リネーム」し、
最後に、リネームされた大元のファイルを「削除」する。
通常は、これが最も安全な保存方法ではあるのだが、
ハードリンクされている文書ファイルの場合、
この作業によってリンクが切れてしまうのだ。
正確に言うと、上書きしたファイルだけが、
ハードリンクから外れ、独立したファイルとなってしまう。
そのため、文書やテキストなど、
アプリケーションで編集するファイルをハードリンクしても、
知らないうちにそれが解除されている可能性があり、
ハードリンクの利点が失われてしまうのである。
そのため、実行可能ファイルをハードリンクし、
複数の場所に置いておいたり、
複数のバージョン名を含む実行可能ファイルを同居させ、
バージョン名が入っていない汎用のファイル名に、
ハードリンクしておいたりと、使い方が限られてしまい、
残念ながら Windows 上ではメリットが少ないと言える。