これらのリンクの明らかでない動作に関するいくつかの事実を続けて共有します。
すぐにコメントします。 ハードリンクではあいまいさが観察されないように見える場合、ソフトリンクまたはシンボリックリンクでは混乱が生じます。 したがって、以下では、 Junctionプログラムによって作成されるシンボリックリンク（およびAlax.Info NTFSリンク、リンクシェル拡張など）について説明します。
実験プログラムは、Total Commander、Far、Frigate3、Servant Salamander、WinDirStat、およびWindows XPのExplorerです。
再帰。
数年前、重複を見つけて削除するための「スーパーデューパー」ユーティリティを作成しようとしていたときに、リンクの問題に最初に遭遇しました。 それ自体または親ディレクトリへのシンボリックリンクを持つディレクトリを処理するときに、OSの検索およびディレクトリトラバーサルメカニズムが再帰に陥ることが判明しました。 もちろん、これはリンクを認識し、ディレクトリとは別に特別な方法でリンクを処理することで回避できます。 しかし、卒業プロジェクトによりユーティリティの開発が中断されたため、次の「重複クリーナー」を作成するために時間を無駄にしないことにしました。 今、私はそれが無駄だと思う。
実際、ファイルを操作するほとんどのプログラムはシンボリックリンクを認識していません。 そして、これはそれが導くものです。
検索。
ディレクトリを作成する
X：\ 000
その中で、text.txtファイルとシンボリックリンク111を同じディレクトリX：\ 000に作成します
これは、Far以外の実験的なファイルマネージャーが
X：\ 000 \ text.txt
X：\ 000 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X：\ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
再帰がこんなに早く中断されたことを嬉しく思います。 それでも、この動作は正しくなく、エラーにつながる可能性があります。 ここでは、同じファイルを16回見つけました。 多くの重複ファインダープログラムは、このファイルを重複として削除することを提案します。 実際には、ファイルは完全に一意です。
しかし、結局のところ、検索時にシンボリックリンクをたどることはありません。
カタログサイズ
この動作は、ディレクトリのサイズを決定する際に興味深い効果をもたらします。 このサイズは、ディスクのサイズよりも何倍も大きくすることができます。 たとえば、ラップトップには300 TBのフォルダーがあります。 ハードリンクを使用して、ディメンションと同じフォーカスを行うことができます。
実験プログラムのうち、WinDirStatとExplorerのみが正しいサイズに設定されました。
エクスプローラーのすべては明確です-彼とWindowsでのシンボリックリンクの実装は、同じ会社の発案であり、独自のリンクメカニズムを誤って使用した場合は奇妙です。 しかし、WinDirStatはリンクに非常に精通しています。おそらくLinuxから来ているからでしょう。
シンボリックリンクをコピーする
リンクをコピーする場合、実験的なファイルマネージャーの動作は異なります。
* Far-リンクとしてコピーされたシンボリックリンク。 つまり そのコンテンツではなくリンクのコピーを作成しました。
* Explorerは各リンクについて質問をしました-ディレクトリまたはリンクとしてコピーします。 しかし、このような賢い動作は、インストールされたAlax.Info NTFS Linksユーティリティによって彼に与えられたのではないかと思います。 拡張機能のないWindows XPではExplorerがどのように動作するかを検証できませんでした。Windows2000では、Explorerはそれ自体をコピーするときと同じように動作します。
*他のすべての実験対象は、リンクをディレクトリとしてコピーしました。
リンクをコピーするときは、それが何であるかを理解する必要があります。 リンクがファイルとしてコピーされる場合、たとえば、近い将来父の「インターネット」をコピーすることはできません。 リンクをリンクとしてコピーすると、シンボリックリンクが内部にあったため、ヘッドライトの別のhddにコピーされた友人の映画のカタログが開かないことがあります。 そして、彼らが言及した場所は別のHDDに残った。 一般的に、コピーするとき、Explorerはインストールされた正しい拡張機能で最も正しく動作します。
次に、アーカイバがシンボリックリンクをサポートしているかどうかを確認することにしました。 いいえということが判明しました。 私のコレクション（7Z、winrarを含む）のすべてのアーカイバは、シンボリックリンクを保存しません。 残念ながら、私のコレクションには、tarのような移植されたアーカイバはありませんでした。 Linuxプログラムが再び役立つことを願っています。
ファイルへのハードリンクについては、すべてのプログラムがリンクを認識または認識せずにファイルとしてコピー、アーカイブします。 原則として、これが期待されています。
シンボリックリンクの削除。
シンボリックリンクを削除すると、Frigate3とServant Salamanderは区別されました。 リンクを削除しただけでなく、参照先のディレクトリの内容も慎重に消去しました。 残りの実験被験者はリンクのみを削除しました。
妄想。
ハードリンクを削除しても問題ありません。 確かに、ファイルが別のハードリンクによって開かれている場合、そのハードリンクを削除できない理由はわかりません。
ハードリンクは本質的に同じファイルの異なる名前であることを覚えておく必要があります。
ファイルを永久に上書きするプログラム（ Sdeleteなど ）を使用する場合、1つのハードリンクを永久に削除すると、ファイルへの残りのハードリンクが大量のゴミを参照することになります。この場合、この動作は論理的で正しいです。 ファイルを上書きする場合は、それで十分です。
結論
おそらくシンボリックリンクはWindowsで人気がなかったため、多くのプログラマーはシンボリックリンクを忘れています。 あるいは、プログラマーがリンクを忘れており、プログラムがリンクを処理する際にリンクが機能するため、リンクは人気がありません。 一般に、シンボリックリンクとハードリンクを使用するときは注意し、ファイルマネージャがそれらをどのように処理するかを確認してください。
脅威。 テーマ別ブログに書くのに十分なカルマがないことがわかりました。 まあ。 たぶんここで誰かが役に立つでしょう。
UPD：実験はMicrosoft Windows XP Home Edition 32ビットSP3で実施されました
総司令官7.04a
ファー1.70
使用人サラマンダー2.0
WinDirStat 1.1.2.80（Unicode）
フリゲート3.21.2.71
エクスプローラー6.00.2900.5512
Buslaの発言を考慮に入れて、Symbolic linkの翻訳をより一般的なバージョンに変更しました。
UPD2：
それが何であるかをもう一度明確にし、軽い手MSでownかれた用語の違いを取り除くために。
msdnを調べた結果、最終的にMSが合意に達したことがわかりました。 のようです。 また、Windows Vistaでは、 CreateSymbolicLink関数によって作成されるシンボリックリンクを作成しました。
そして、それらのシンボリック==シンボリック==初期バージョンのWindows（2000、XP）にあった（そしてある）ソフトリンクは、ある種の再解析ポイントです。 そして、彼らは次のようなものを作成します：
memset（reparseInfo、0、sizeof（* reparseInfo））;
reparseInfo-> ReparseTag = IO_REPARSE_TAG_MOUNT_POINT;
reparseInfo-> ReparseTargetLength =
_tcslen（targetNativeFileName）* sizeof（WCHAR）;
reparseInfo-> ReparseTargetMaximumLength =
reparseInfo-> ReparseTargetLength + sizeof（WCHAR）;
_tcscpy（reparseInfo-> ReparseTarget、targetNativeFileName）;
reparseInfo-> ReparseDataLength = reparseInfo-> ReparseTargetLength + 12;
DeviceIoControl（
hFile
FSCTL_SET_REPARSE_POINT、
reparseInfo、
reparseInfo-> ReparseDataLength + REPARSE_MOUNTPOINT_HEADER_SIZE、
NULL
0
返された長さ、
NULL）;
それで、私にはホイストがないので、再解析ポイントについて話しています。 シンボリックリンクは、さまざまなプログラムでのあいまいな動作にも驚きをもたらすと思いますが。 問題は主にリンクにあるのではなく、一部のプログラマーがリンクを忘れているという事実にあるためです。