Мне просто интересно, как система Windows обрабатывает символические ссылки. Я думаю, что он их не узнает, но я не совсем уверен.
Кроме того, что делают Mac, когда сталкиваются с одним?
Мне просто интересно, как система Windows обрабатывает символические ссылки. Я думаю, что он их не узнает, но я не совсем уверен.
Кроме того, что делают Mac, когда сталкиваются с одним?
Ответы:
Зависит от версии Windows и конфигурации на стороне сервера, когда мы говорим о нелокальных дисках.
Начиная с Windows Vista, в Windows есть идея символических ссылок, но семантика отличается. Но более важной проблемой здесь должны быть имена путей, которые следуют другому синтаксису. Для начала: однокорневое дерево каталогов на стороне Unixoid и несколько букв дисков в качестве корней на стороне Windows.
На стороне Unixoid символические ссылки - это просто текстовые файлы со специальным флагом. На стороне 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
все не изменится вообще.
Суть: так что это возможно, что вы можете заставить это работать для некоторых угловых случаев, тот факт, что семантика и синтаксис различаются по обе стороны ограждения, делает маловероятным, что вы найдете практичный и универсальный метод, который работает.
ntfs
поддерживает точки монтирования (если вам не нравятся все эти буквы).
Ответ 0xC0000022L является исчерпывающим для стороны Windows. Mac может распознавать символические ссылки Linux; однако Linux не может распознать псевдонимы, сделанные в Finder Mac (символические ссылки, созданные с помощью ln -s, работают нормально).
.lnk
файлы).