UFSやExt2といったいわゆるUNIX系ファイルシステムでは、複数のファイル名に対して同じiノードを対応づけることが可能であり、これを利用した特有の仕掛けがハードリンクだ(図4)。ハードリンクを使うと、複数のファイル名が同じファイルの実体を指すことができる。
似た実装に、Windowsのショートカット、Macのエイリアス、そしてUNIXのシンボリックリンクなどがあるが、これらは本体となるファイルに対する別名を定義するだけで、それぞれ本体のファイルを指定するためのデータ領域を必要とする。ハードリンクはそれぞれ対等で主従関係がなく、また消費するのはディレクトリエントリだけでそれ以上に領域を使用しないというメリットがある。
ハードリンクはそもそもiノードを使用したファイルシステム特有の仕組みであり、そのためHFS Plusではそうした枠組みは本来的には存在しない。しかしMac OS XはUNIXとしての側面も持つOSであり、ハードリンクが使えないというのはかなり問題となる。
このためHFS Plusファイルシステムレイヤーでは「kernel-level symbolic link」という機能を用意しハードリンクの代わりに用いている。
まず、通常にファイルが作成された場合、普通にファイルが作成される。こうしたすでに存在するファイルに対してハードリンクを作成しようとしたとき、そのファイル本体はHFS Plusファイルシステムレイヤーの持つ、/からたどることのできない、階層構造から外された隠しディレクトリにファイルを移動する。そして、リンク元、リンク先の双方にハードリンクファイルを作成するのだ。このハードリンクファイルは、クリエータに「hfs+」、ファイルタイプに「hlnk」という値を持ち、隠しディレクトリに隠されたファイルを指すように仕向けられている(図5)。
すでにリンクのあるファイルにハードリンクを行った場合は、ただリンク先にハードリンクファイルを作成、リンクカウントを加算するだけだ。すべてのハードリンクファイルが削除された場合に限り、隠しディレクトリにある本来のファイルも削除される。
ハードリンクファイルから本来のファイルを探す処理はシステムコールより下の、HFS Plusファイルシステムレイヤーで行われるため、BSD、Carbon、CocoaのどのAPIからも本来のファイルとして扱われ、これをユーザーランドから検知する術はない*。
Mac OS 9のようにHFS Plusを理解する、かつkernel-level symbolic linkに非対応のOSを使うことで検出できる。しかし、不用意にハードリンクファイルを操作するとリンクが壊れてしまうので、こうした古いOSでのアクセスはやめた方が良い。
本記事は、オープンソースマガジン2006年3月号「Undocumented Mac OS X」を再構成したものです。
Copyright © ITmedia, Inc. All Rights Reserved.