このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
マウントポイント機能は、
使い方次第では非常に便利である。
ディスクを複数のパーティションに分けている場合、
システムドライブに空き容量が不足しても
マウントポイント機能を使えば、
ドライブにある適当なディレクトリの実体を、
別のボリュームに置くことができる。
ボリュームマウントポイントの場合は、
Windows で正式にサポートされているため、
GUI によって設定することもできるが、
別のボリューム全体がマウントされることになる。
これは、空きボリュームがある場合は最適な選択であるが、
そうである場合は少し使いにくい。
例えば、C と D のドライブに分けるのは良くある例だが、
大抵の場合、C にも D にも色々とデータを置いている。
ここで C ドライブの容量が不足したとしても、
C ドライブ内の適当なディレクトリに、
D ドライブ全体をマウントするのは現実的ではない。
なぜなら、D ドライブに含まれる色々なディレクトリも
一緒にぶら下がってしまうため、
マウントポイント配下が混沌としてしまうからだ。
容量の為ならと妥協することもできるかもしれないが、
データの分類や整理が難しくなり、
バックアップを取るのも面倒になってしまう。
ディレクトリジャンクションを使う場合は自由度が高い。
C ドライブ内の適当なディレクトリに、
任意のディレクトリをマウントすることができる。
D ドライブに新しいディレクトリを作成し、
そのディレクトリだけをマウントすることもできるので、
効率良く扱うことができるようになる。
ただ、これらマウントポイントには、
使い方によっては、大きな問題を起こすことがある。
何が問題かと言えば、マウントポイントを削除する時に、
マウント先のデータも削除されてしまう場合があるのだ。
これは、エクスプローラをはじめとする、
ファイル管理系ソフトの機能と関係している。
Windows のファイル管理ソフトウェアは、
ディレクトリを削除する機能を持っているが、
その処理方法は、ディレクトリ内の全てのファイルや、
サブディレクトリを探索して削除するという手法である。
この方法では、マウントポイント自身を削除する場合や、
削除するディレクトリの内部に、
マウントポイントが存在する場合に問題が起きる。
マウントポイントは、ファイルシステムの機能であるため、
ソフトウェア上では、その存在は透過的に扱われる。
そのため、大半のソフトウェアでは、
ただのディレクトリとして扱われることになる。
その結果、マウントポイントを削除する際は、
マウントポイントが指し示す先のデータを、
丸ごと削除してしまうという危険要素を持っているのである。
そもそも、API やシステムコールの水準で
ディレクトリの削除をする場合は、
ディレクトリが空でないと消すことができない。
また、マウントポイントは空のディレクトリ扱いなので、
マウント先のデータに影響を与えずに削除できる。
そのため、Windows のコマンドプロンプトにおいて、
rmdir を使う場合はデータの消失は起きないが、
利便性を考えた GUI では問題が起きてしまうのだ。
（但し、rmdir に /s スイッチをつけると同じ問題が起きる）
同じ理由で、マウントポイントを他のドライブに移すと、
本来のリンク先に存在するデータを移動してしまい、
移動先のドライブではただのディレクトリになってしまう。
注意深いソフトウェアであれば、
ディレクトリの属性を調べて認識するかもしれないが、
NTFS の新機能に対応しているのはそれほど多くない。
ボリュームマウントポイントの場合は、エクスプローラでは
ディスクのアイコンに変わるので区別がつくのだが、
ディレクトリジャンクションは、GUI 上では、
ただのディレクトリと区別がつかないので厄介である。
コマンドプロンプトでは、dir コマンドを使うことで、
マウントポイントは <JUNCTION> と表示される。
通常のディレクトリは <DIR> なので区別することはできる。
マウントポイントを使う場合は、
利用者が常に意識して、注意深く取り扱う必要があるのだ。