Сценарій

17

Відмінності

┌─────────────────────────────────────────────────── ───────┬─────┐
│ │ Абсолютний lative Відносний │ Файл │ Каталог │ UNC │
├─────────────────────────────────────────────────── ───────┼─────┤
│ Символічне посилання │ Так │ Так │ Так │ Так │ Так │
│ З'єднання │ Так │ - │ - │ Так │ - │
└─────────────────────────────────────────────────── ───────┴─────┘

Припустимо, ми створюємо точку повторного аналізу для створення переадресації C:\SomeDir => D:\SomeDir

Оскільки для цього сценарію потрібні лише локальні, абсолютні шляхи, то з'єднання чи символьна посилання спрацювали б. Чи є в цій ситуації якась перевага використання того чи іншого?

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

Оновлення

Я знайшов іншу різницю.

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

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

Оновлення 2

Windows 8.1 вирішить символічні посилання каталогів під час переходу до одного через текстове поле у Save As...діалоговому вікні. З'єднання не розширюються.

Чи є у вас посилання на інформацію про різницю дозволів? Це цілком знахідка.

— surfasb

Моє тестування підтверджує, що доступ для читання до цільового каталогу (тобто перелік вмісту каталогів) обмежений дозволами на точку з'єднання, крім дозволу на цільовому каталозі. Однак жоден інший доступ не впливає на це. Зокрема, ви можете створювати файли та папки, якщо цільовий каталог дозволяє, незалежно від дозволів точки з'єднання.

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

@HarryJohnston: Спочатку я підозрював деяку невідповідність, оскільки я блокував видалення та записування дозволів на з'єднання, але елементи та підпапки внизу добре.

— surfasb

Я не зроблю це повноцінною відповіддю, якщо не вимагаю, але якщо ви використовуєте GNU або іншу не-Windows систему для доступу до тома через mount.cifs, тоді символьні посилання з’являться як такі, тоді як стики будуть розглядатися як звичайні каталоги - можливо, через точка, де відбувається роздільна здатність IO, тобто локально на хості Windows.

— can-ned_food

4

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

— Гаррет
джерело

За замовчуванням символьні посилання на серверах будуть ігноруватись, і навіть якщо їх дотримуватись, обмежуватимуться правилами доступу до доступу на рівні сервера: так, наприклад, ви не можете передати посилання на місцеположення на сервері, яке не надане спільним доступом, або якщо доля не надає користувачеві доступу. Таким чином, посилання не можуть замінити точки з'єднання у всіх контекстах.

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

2

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

Якщо це не підтримується, точка посилання / з'єднання буде або резервна копія як окремий каталог (і відновлена як така), або взагалі не буде створено резервну копію.

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

— haimg
джерело

З'єднання точок та символьних посилань реалізуються через NTFS з використанням точок повторного аналізу. Згідно з MSDN, вони обидва трактуються однаково за допомогою файлових операцій через API.

— surfasb

2

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

— haimg

Ах, дуже гарна точка! Я не думав досить далеко попереду.

— surfasb

Наскільки я знаю, це важливіше, якщо до гучності будуть доступні старіші ОС Windows.

— can-ned_food

1

Переходи NTFS можна вказувати лише на каталоги, тоді як символьні посилання також працюють на файли.

— користувач1686
джерело

Але для файлів ви можете використовувати жорстке посилання замість цього.

— парадороїд

0

Ось одна відмінність, яку я помітив:

У мене є синхронізований каталог сценаріїв, портативних програм тощо. Я використовую пакетний скрипт, щоб здійснити з'єднання в каталозі меню «Пуск», яке вказує на каталог ярликів для портативних програм.

З'єднання дозволяє ярлики з'являтися в меню "Пуск". Коли я замість цього використовую Symbolic Link, це не працює.

— парадіроїд
джерело

Як не дивно, це добре працює для мене. У мене також є посилання на флешки, підключені до моєї машини.

— surfasb

@surfasb: Ви впевнені, що робите те, що я описав? Ярлики в каталозі, на які вказує символічне посилання з каталогом меню "Пуск", не відображаються в моєму меню "Пуск". Вони роблять, коли замість цього використовується перехід.

— парадороїд

Не впевнений, чи правильно я це прочитав. Отже, у меню запуску символьне посилання, яке вказує на папку, яка містить ярлики? Я спробував це тільки зараз. Я навіть отримав симпосилання, щоб вказати на інше символьне посилання на unc шлях, який із ярликами вказував на папку на шляху UNC. Звичайно, це порушує ярлики. Але обхід символьної лінії "віддалений до віддаленого" відключений за замовчуванням у Windows.

— surfasb

0

Можливо, я пропустив це десь у коментарях, але одна дуже важлива різниця між символьними посиланнями та переходами в Windows для мене - це необхідні привілеї для створення обох. Незважаючи на те, що символьні посилання за замовчуванням створюються лише за допомогою спеціальних дозволів, які за замовчуванням користувачі не мають, з'єднання можуть бути легко створені усіма користувачами OOB за замовчуванням, і тому є моїм кращим типом посилань для dirs.

За замовчуванням члени групи адміністраторів мають це право.

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

— Торстен Шьонінг
джерело