Вопрос: "Directory junction" vs "directory symbolic link"?


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

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

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

  1. Это не соединение каталога то же самое, что и справочная символьная ссылка?

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

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


332
2017-10-05 03:28


Источник


Связанный: superuser.com/q/347930/24500 - surfasb


Ответы:


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

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

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

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

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

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

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

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


312
2017-10-22 19:03



Чтобы быть ясным: вполне могут быть другие более тонкие функциональные различия между узлами каталогов и символическими ссылками каталога. Удаленная и локальная вещь является самой очевидной из перспективы пользователя (в отличие от разработчика). - Harry Johnston
@MatthewSteeples вы имеете в виду, что если я создам символическую ссылку C:\testlink (что указывает на C:\test на моем компьютере) и кто-то удаленный доступ к моему компьютеру и нажимает на C:\testlink, это решило бы C:\test на HIS-компьютере, если я создаю соединение с каталогом C:\testlink (что указывает на C:\test на моем компьютере), и кто-то удаленный доступ к моему компьютеру и нажимает на C:\testlink) это приведет его к C:\test на моем компьютере? Или я ошибался? - Pacerier
@Pacerier в этом контексте да, но символические ссылки позволяют вам иметь папку на вашем компьютере, которая указывает на общий сетевой ресурс (поскольку они разрешены на стороне клиента). Например, C: \ MyNetworkShare может на самом деле указывать на \\ Alice \ Share - Matthew Steeples
@MatthewSteeples, но мы не могли создать соединение с каталогом C:\MyNetworkShare что указывает на \\Alice\Share также? - Pacerier
@Pacerier, нет, точки соединения должны быть локальными. - Harry Johnston


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

Предположим, что 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 - Если вы разблокировали доступ к удаленным символическим ссылкам на вашем локальном компьютере, тогда это сработает ... но только на локальном компьютере, где он разблокирован


42
2018-02-02 16:30



Это так странно. Даже относительные символические ссылки не работают удаленно. Например. Я создаю каталог d:\_tmp\data, Создайте ссылку так: d:\_tmp>mklink /d data-link data, Удаленный пользователь имеет полный доступ к d:\_tmp и все его подпапки, но он все равно не сможет открыть d:\_tmp\data-link, - Nux
Это связано с тем, что когда символическая ссылка оценивается на стороне клиента, она указывает на d: \ _ tmp \ data на клиенте, а не на сервере. - apraetor
Я думаю, что причина, по которой это странно, ясна. Но я согласен с @Nux, что это странно, по крайней мере, в случае относительных символических ссылок. - Jon Coombs


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

enter image description here

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


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

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

Взято отсюда (хороший вводный текст)

enter image description here

Из Страница SS64 на MKLink

enter image description here


Комментарии о Терминологии

Переходы - символические ссылки

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

NTFS

Несмотря на то, что ОП указывает это, стоит отметить, что «символическая ссылка» - это очень общий термин, не относящийся к NTFS. Так что, если быть конкретным, это сравнение относится к NTFS Unctions vs. NTFS Symbolic Links.


12