Сценарий

17

Различия

┌───────────────┬──────────┬──────────┬──────┬──── ───────┬─────┐
│ │ Абсолютный │ Относительный │ Файл │ Каталог │ UNC │
├───────────────┼──────────┼──────────┼──────┼──── ───────┼─────┤
│ Символическая ссылка │ Да │ Да │ Да │ Да │ Да │
│ перекресток │ да │ - │ - │ да │ - │
└───────────────┴──────────┴──────────┴──────┴──── ───────┴─────┘

Давайте предположим, что мы создаем точку повторной обработки для создания перенаправления C:\SomeDir => D:\SomeDir

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

Предположим Windows 7 для ОС, не учитывая обратную совместимость. (До Vista, символические ссылки изначально не поддерживаются, хотя существует сторонний драйвер, который обеспечивает поддержку символических ссылок в Windows XP.)

Обновить

Я нашел другое отличие.

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

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

Обновление 2

Windows 8.1 будет разрешать символические ссылки на каталоги при переходе по ним через текстовое поле в Save As...диалоговом окне. Соединения не расширены.

У вас есть ссылка на информацию о разнице в разрешениях? Это настоящая находка.

— Surfasb

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

— Гарри Джонстон

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

— surfasb

Я не буду делать это полным ответом, если не будет запрошено, но если вы используете GNU или другую систему, отличную от Windows, для доступа к тому через mount.cifs, тогда символические ссылки будут отображаться как таковые, тогда как переходы будут рассматриваться как обычные каталоги - вероятно, из-за точка, где происходит разрешение ввода-вывода, то есть локально на хосте Windows.

— can-ned_food

4

Я понимаю, что символические ссылки NTFS являются заменой для переходов в более новых ОС Windows (Vista / 7/8), поскольку они функционируют аналогичным образом, но также предоставляют дополнительную функциональность (удаленные точки). Поэтому, если вы работаете только с более новыми операционными системами, нет никаких причин не использовать опцию символической ссылки.

— Garrett
источник

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

— Гарри Джонстон

2

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

Если не поддерживается, точка символической ссылки / соединения будет либо сохранена в виде отдельного каталога (и восстановлена как таковая), либо не будет сохранена вообще.

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

— haimg
источник

Точки соединения и символические ссылки реализованы через NTFS с использованием точек повторной обработки. Согласно MSDN, они оба обрабатываются одинаково при файловых операциях через API.

— Surfasb

2

@surfasb: Однако, если символические ссылки специально не поддерживаются (и распознаются как таковые), они не будут воссозданы как символические ссылки во время восстановления из резервной копии.

— Haimg

Ах, очень хорошая мысль! Я не думал достаточно далеко вперед.

— Surfasb

Насколько я знаю, это более важно, если к тому будут обращаться старые ОС Windows.

— can-ned_food

1

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

— user1686
источник

Но для файлов вы можете использовать жесткую ссылку.

— paradroid

0

Вот одно отличие, которое я заметил:

У меня есть каталог синхронизированных сценариев, переносимых приложений и т. Д. Я использую пакетный сценарий для создания соединения в каталоге меню «Пуск», которое указывает на каталог ярлыков для переносимых приложений.

Junction позволяет ярлыкам появляться в меню «Пуск». Когда я использую символическую ссылку, она не работает.

— Paradroid
источник

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

— Surfasb

@surfasb: Вы уверены, что делаете то, что я описал? Ярлыки в каталоге, на который указывает символическая ссылка с каталогом меню «Пуск», не отображаются в моем меню «Пуск». Они делают, когда вместо этого используется Junction.

— paradroid

Не уверен, что правильно прочитал. Итак, в меню «Пуск» символическая ссылка, указывающая на папку, содержащую ярлыки? Я попробовал это только сейчас. Я даже получил символическую ссылку, указывающую на другую символическую ссылку в unc-пути, которая указывала на папку в UNC-пути с ярлыками. Конечно, это ломает ярлыки. Но обход по символическим ссылкам «от удаленного к удаленному» по умолчанию отключен в Windows.

— Surfasb

0

Может быть, я пропустил это где-то в комментариях, но одно очень важное различие между символическими ссылками и соединениями в Windows для меня - необходимые привилегии для создания обоих. Хотя символические ссылки по умолчанию могут создаваться только с использованием специальных разрешений, которых у пользователей по умолчанию нет, переходы могут быть легко созданы всеми пользователями OOB по умолчанию, и поэтому я предпочитаю ссылочный тип для директорий.

По умолчанию члены группы «Администраторы» имеют это право.

https://docs.microsoft.com/en-us/windows/device-security/security-policy-settings/create-symbolic-links

— Торстен Шенинг
источник