マウントポイント機能は、
使い方次第では非常に便利である。

ディスクを複数のパーティションに分けている場合、
システムドライブに空き容量が不足しても
マウントポイント機能を使えば、
ドライブにある適当なディレクトリの実体を、
別のボリュームに置くことができる。

ボリュームマウントポイントの場合は、
Windows で正式にサポートされているため、
GUI によって設定することもできるが、
別のボリューム全体がマウントされることになる。

これは、空きボリュームがある場合は最適な選択であるが、
そうである場合は少し使いにくい。

例えば、C と D のドライブに分けるのは良くある例だが、
大抵の場合、C にも D にも色々とデータを置いている。
ここで C ドライブの容量が不足したとしても、
C ドライブ内の適当なディレクトリに、
D ドライブ全体をマウントするのは現実的ではない。

なぜなら、D ドライブに含まれる色々なディレクトリも
一緒にぶら下がってしまうため、
マウントポイント配下が混沌としてしまうからだ。

容量の為ならと妥協することもできるかもしれないが、
データの分類や整理が難しくなり、
バックアップを取るのも面倒になってしまう。

ディレクトリジャンクションを使う場合は自由度が高い。
C ドライブ内の適当なディレクトリに、
任意のディレクトリをマウントすることができる。

D ドライブに新しいディレクトリを作成し、
そのディレクトリだけをマウントすることもできるので、
効率良く扱うことができるようになる。

ただ、これらマウントポイントには、
使い方によっては、大きな問題を起こすことがある。
何が問題かと言えば、マウントポイントを削除する時に、
マウント先のデータも削除されてしまう場合があるのだ。

これは、エクスプローラをはじめとする、
ファイル管理系ソフトの機能と関係している。

Windows のファイル管理ソフトウェアは、
ディレクトリを削除する機能を持っているが、
その処理方法は、ディレクトリ内の全てのファイルや、
サブディレクトリを探索して削除するという手法である。

この方法では、マウントポイント自身を削除する場合や、
削除するディレクトリの内部に、
マウントポイントが存在する場合に問題が起きる。

マウントポイントは、ファイルシステムの機能であるため、
ソフトウェア上では、その存在は透過的に扱われる。
そのため、大半のソフトウェアでは、
ただのディレクトリとして扱われることになる。

その結果、マウントポイントを削除する際は、
マウントポイントが指し示す先のデータを、
丸ごと削除してしまうという危険要素を持っているのである。

そもそも、API やシステムコールの水準で
ディレクトリの削除をする場合は、
ディレクトリが空でないと消すことができない。
また、マウントポイントは空のディレクトリ扱いなので、
マウント先のデータに影響を与えずに削除できる。

そのため、Windows のコマンドプロンプトにおいて、
rmdir を使う場合はデータの消失は起きないが、
利便性を考えた GUI では問題が起きてしまうのだ。
(但し、rmdir に /s スイッチをつけると同じ問題が起きる)

同じ理由で、マウントポイントを他のドライブに移すと、
本来のリンク先に存在するデータを移動してしまい、
移動先のドライブではただのディレクトリになってしまう。

注意深いソフトウェアであれば、
ディレクトリの属性を調べて認識するかもしれないが、
NTFS の新機能に対応しているのはそれほど多くない。

ボリュームマウントポイントの場合は、エクスプローラでは
ディスクのアイコンに変わるので区別がつくのだが、
ディレクトリジャンクションは、GUI 上では、
ただのディレクトリと区別がつかないので厄介である。

コマンドプロンプトでは、dir コマンドを使うことで、
マウントポイントは <JUNCTION> と表示される。
通常のディレクトリは <DIR> なので区別することはできる。

マウントポイントを使う場合は、
利用者が常に意識して、注意深く取り扱う必要があるのだ。