システム内に散在する設定ファイルを一カ所に集め,管理効率を上げたいという要望はないだろうか。UNIX系OSにはファイルを別名で参照する「シンボリックリンク」という機能があり,これを利用することで実現可能だ。

 リンク先の実ファイルとシンボリックリンクは同等に扱えるため,どちらからどちらにリンクを張ってもよいと思われるかもしれないが,そうではない。

 リンクには,ハードリンクとシンボリックリンクの二つがある。UNIX系OSのファイル・システムでは,ファイルに複数のファイル名を付けることができる。一つのファイルに対し,複数の実名を付ける処理がハードリンクである。ハードリンクの場合,複数あるファイル名はどれも対等なものとなる。

 これに対しシンボリックリンクは,別名を付けることに相当する。シンボリックリンクを作成すると,新たにファイルが生成され,その内容として,リンク先のファイル名とパスが保持される。この情報を基にリンク先ファイルにアクセスする仕組みだ。

 以上の仕組みにより,二つのファイル名で同一のファイルへアクセスすることが要件の場合,本来ハードリンクを用いるほうが都合がよい。ただし,ハードリンクには,デバイスやパーティションを越えてリンクを張ることができないという制約がある。また,多くのファイル・システムでは,ディレクトリのハードリンクを容易に作成できない。これらのことから,実際にはシンボリックリンクが多用される。

コピーと移動で上書きされるファイルが異なる

図1●cpコマンドとmvコマンドの挙動の違い
図1●cpコマンドとmvコマンドの挙動の違い
[画像のクリックで拡大表示]

 シンボリックリンクは,ファイル・システムのレイヤーで処理されるため,プログラムからファイル名を指定してファイルにアクセスする場合,実ファイル名とほぼ同等に扱える。しかし,ファイル名自体を扱うような処理を実行する場合には,実ファイル名と同じように使用すると問題が発生するので注意が必要だ。

 具体的には,ファイルの移動(mv),コピー(cp)などの操作や,ファイルのアーカイブ(tar)処理などである。

 例えば,実ファイルでシンボリックリンク・ファイルを上書きするような処理をした場合,コピーコマンド(cp)と移動コマンド(mv)ではその結果が異なる。図1に示すようなコマンドを実行すると,cpコマンドでは,参照先の実ファイルが更新されるのに対し,mvコマンドでは,シンボリックリンクが上書きされる。

シンボリックリンクは読み取り専用で使う

図2●シンボリックリンクを利用した設定ファイルの集約
図2●シンボリックリンクを利用した設定ファイルの集約

 こういったコマンド実行結果の差異を意識しなくてよいよう,シンボリックリンクは読み取り専用とし,変更が必要な場合は,実ファイルのほうを変更するルールとすべきである。

 複数ディレクトリに散在する設定ファイルの更新を効率化するため,一つのディレクトリ配下に集約するとしよう(図2)。この場合,シンボリックリンクに対するファイル操作は避けるという方針に従い,編集目的として配置する設定集約用ディレクトリ(図2では「ext」)に実ファイルを配置し,そのファイルに対してシンボリックリンクを張るようにする。こうすることで,集約用ディレクトリ配下に実ファイルが揃うため,これらのファイル操作に神経を使うことはない。

 もう一つ,シンボリックリンクを利用する上で注意しなければならないのは,シンボリックリンクの遅延評価の性質である。シンボリックリンクを作成した時点ではリンク先のファイルに意図したファイルが存在したとしても,その後もそのファイルが存在し続けることは保証されない。ファイルが削除され,いわゆる「リンク切れ」の状態となり得る。例えファイルが存在しても別の実体のファイルかもしれない。

大上 貴充(おおがみ たかみつ)
NTTデータ 基盤システム事業本部 システム方式技術ビジネスユニット OSS技術統括 アソシエイトITスペシャリスト(プラットフォーム)
日頃はオリジナルOSSを中心に,技術開発やそのビジネス化に従事。OSをはじめ、Javaやクラスタミドルといった,アプリケーションの基礎となる技術分野を極めるべく,日夜奮闘中。