"каталог соединения" против "символьная ссылка каталога"?

Question

В контексте NTFS:

MKLINK [[/D] | [/H] | [/J]] Link Target

/D Создает каталог символическую ссылку. По умолчанию это символьная ссылка на файл.
/H Создает жесткую ссылку вместо символической ссылки.
/J Создает перекрестный каталог.
Link указывает новое символическое имя ссылки.
Target указывает путь (относительный или абсолютный), на который ссылается новая ссылка.

1. Разве соединение каталогов - это не то же самое, что символьная ссылка на каталог ?

   В чем разница между mklink /D f1 f2 и mklink /J f1 f2 ?

2. Поскольку "каталог" на самом деле является просто файлом, в чем будет разница между символической ссылкой каталога и символической ссылкой файла?

Answer 1

Соединение определенно не то же самое, что символьная ссылка на каталог, хотя они ведут себя аналогично. Основное отличие состоит в том, что, если вы смотрите на удаленный сервер, соединения обрабатываются на сервере, а символические ссылки каталога обрабатываются на клиенте. Также см. Комментарий Мэтью о том, что это означает, что символические ссылки в локальной файловой системе могут указывать на удаленные файловые системы.

Предположим, что на компьютере с именем Alice вы должны были поместить точку соединения c:\myjp и символическую ссылку каталога c:\mysymlink , обе из которых указывают на c:\targetfolder . Пока вы используете Алису, вы не заметите большой разницы между ними. Но если вы используете другую машину с именем Bob, то точка соединения

\\Alice\c$\myjp будет указывать на \\Alice\c$\targetfolder

но символическая ссылка

\\Alice\c$\mysymlink будет указывать на \\Bob\c$\targetfolder

(Предостережение: по умолчанию система не следует символическим ссылкам на удаленных томах, поэтому в большинстве случаев второй пример фактически приводит либо к "файлу не найден", либо к «Символической ссылке не может следовать, поскольку ее тип отключен».)

Разница между символической ссылкой каталога и символической ссылкой файла заключается просто в том, что один представляет каталог, а другой - файл. Поскольку целевая ссылка не должна существовать при создании ссылки, файловая система должна знать, сообщать ли приложениям, что это каталог или нет.

Следует также отметить, что для создания символической ссылки требуются специальные привилегии (по умолчанию они доступны только для процессов с повышенными правами), тогда как для создания соединения требуется только доступ к файловой системе.

Answer 2

Сложный разговор вредит мозгу - мне нравятся графики:

Предположим, что любой MyLink является символической ссылкой, а любой MyJunc является соединением, указывающим на Target as created .

например

mklink /D MyLink C:\T_Dir для создания символической ссылки на целевой каталог

mklink /J MyJunc C:\T_Dir для создания соединения каталога с целевым каталогом

Где синтаксис mklink [/J,/D] [link path] [target path] как набрано на локальной машине

---

 link path    |   target path   |         When accessed ..
              |                 |  (locally)    |    (remotely)
              |                 |               |
C:\MyLink     |   C:\T_Dir      |  C:\T_Dir     |  [leads back to local]
C:\MyJunc     |   C:\T_Dir      |  C:\T_Dir     |  [leads to remote]
              |                 |
\\Svr\MyLink  |   C:\T_Dir      |   C:\T_Dir    |  [leads back to local]
\\Svr\MyJunc  |   C:\T_Dir      |  *** Must create and point local ***
              |                 |
C:\MyLink     |  \\Sv2\T_Dir    |  \\Sv2\T_Dir  |   Error*1
C:\MyJunc     |  \\Sv2\T_Dir    |  *** Error - Must point local ***
              |                 |
\\Svr\MyLink  |  \\Sv2\T_Dir    |  Error*1
\\Svr\MyJunc  |  \\Sv2\T_Dir    |  *** Must create link using target device ***

Ошибка * 1 - Если вы разблокировали доступ к удаленным символическим ссылкам на локальном компьютере, это сработало бы ... но только на локальном компьютере, на котором он разблокирован

Answer 3

У меня сложилось впечатление, что узлы были просто по старым причинам, и символические связи были в целом лучше (вещи выглядят таким образом за чистую монету). Оказывается, это не совсем так. Есть несколько веских причин использовать соединение вместо символической ссылки. Основное различие сводится к безопасности и удаленным и локальным путям. Да, удаленный таргетинг делает символические ссылки более функциональными, но также повышает их профиль безопасности. Так что, если вы хотите локальную ссылку и можете жить по абсолютному пути, вам, вероятно, лучше с перекрестком; в противном случае рассмотрите символическую ссылку для его добавленных способностей.

** Заявление о разнице в скорости / сложности исходит из непроверенного утверждения в записи Википедии о точках повторной обработки NTFS (хорошее чтение).*

---

Другие сравнения ссылок NTFS

Вот некоторые другие сравнения по этой теме, но они могут вводить в заблуждение при рассмотрении пересечений, потому что они не перечисляют преимущества, которые я перечислю выше.

Взято отсюда (хорошее вступительное чтение)

Со страницы SS64 на MKLink

---

Отзывы о терминологии

Соединения - это символические ссылки

Соединения и символические ссылки в действительности выполняют одно и то же (точки повторного анализа), за исключением вышеупомянутых различий в том, как они обрабатываются. Фактически, технически, Junction - это символическая ссылка, и иногда документация может назвать Junction символической ссылкой, как в данном случае. Так что это просто кое-что, чтобы знать о терминологии.

NTFS

Несмотря на то, что OP указывает это, стоит отметить, что "символическая ссылка" является очень общим термином, который не является специфическим для NTFS. Таким образом, чтобы быть точным, это сравнение касается соединений NTFS и символических ссылок NTFS.