Чи визнає Windows символічні посилання Linux?

Мені було просто цікаво, як система Windows обробляє символічні посилання. Я найкраще здогадуюсь, що він їх не впізнає, але я не зовсім впевнений.

Крім того, що роблять Маки, коли стикаються з одним?

Залежить від версії Windows та конфігурації на сервері, коли ми говоримо про не локальні диски.

З Windows Vista, Windows має уявлення про символічні посилання, але семантика відрізняється. Але більш важливою проблемою тут повинні бути назви шляхів, які слідують за різним синтаксисом. Для початку: однокореневе дерево каталогів на unixoid стороні та кілька букв диска як корені на стороні Windows.

На однобічній стороні символьних посилань - це лише текстові файли зі спеціальним прапором. З боку Windows основний механізм називається точкою повторного розбору. Це спонукає менеджер об'єктів передавати його певним зареєстрованим фільтрам (мета-дата для цього зберігається в точках перезавантаження). Windows 2000 вже представив один тип точок повторного розбору, відомих як точки з'єднання (приблизно, але не зовсім, символьні посилання). З Vista вони представили посилання як на файли, так і на каталоги, також на віддалені диски. І посилання на віддалених накопичувачах також певною мірою підтримуються.

Основний момент полягає в тому, чи драйвер файлової системи, коли він працює локально, буде вносити будь-які коригування шляхів, які має бачити Windows. У такому випадку це спрацювало б для певних локальних / відносних символьних посилань. Для абсолютних шляхів як цілей речі буде важко і неможливо зробити висновок про те, що мається на увазі. Те ж саме для віддалених посилань на посилання (до "мережевих спільних ресурсів").

Щодо сторони Mac, я поняття не маю, і це може мати сенс як окреме питання. Але поки сервер передає інформацію про те, що це симпосилання, я не бачу проблем, оскільки вони обидва дотримуються семантики SUS (на відміну від Windows).

Розглянемо точки монтажу на стороні Linux:

/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var

А тепер розглянемо симпосилання, що /home/paul/fstabвказує на /etc/fstab. Вони розміщені на двох різних томах, які Windows - якщо зможе побачити їх через драйвер файлової системи (який справді працює!) - не може сказати, що належать разом так, як /etc/fstabце описано. Таким чином, посилання, яке Windows побачила б у папці \paul\fstab, навіть якщо було перекладено, вказувало б на \etc\fstabяке не існує /dev/sda2. І якби це символьне посилання вказувало б на відносний шлях, ../../etc/fstabречі взагалі не змінилися б.

Суть: Отже, хоча це можливо, ви можете змусити це працювати для деяких кутових випадків, той факт, що семантика та синтаксис відрізняються з обох боків огорожі, малоймовірно, що ви знайдете практичний та загальний метод, який працює.

Відповідь 0xC0000022L є ретельною для Windows. Mac може розпізнавати посилання Linux; однак Linux не може розпізнати псевдоніми, створені в Finder Mac (символьні посилання, створені за допомогою ln -s, працюють добре).