Как приложения обрабатывают символические ссылки Windows?

Question

Я думал, что символические ссылки в Windows 10 ведут себя аналогично символическим ссылкам в Linux, то есть они прозрачны для приложений. Тем не менее, я смущен фактическим поведением.

В качестве примера, я софт-линк и жестко связал один и тот же файл CSS:

$ mklink softlinked.css Default.css
symbolic link created for softlinked.css <<===>> Default.css

$ mklink /H hardlinked.css Default.css
Hardlink created for hardlinked.css <<===>> Default.css

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

Кроме того, когда CSS используется редактором Caret, жестко связанная таблица стилей работает нормально:

в то время как softlinked сломан:

Вопросы:

1. Как символические ссылки на самом деле ведут себя в Windows?
2. Можно ли сделать программные ссылки прозрачными для приложений? Под прозрачным я подразумеваю, что приложение всегда будет видеть файл как находящийся по символической ссылке (...\symlinked.css) и никогда не разрешать исходный путь (...\Default.css). Есть какие-то настройки реестра Windows или что-то?

Answer 1

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

Однако они не прозрачны для приложений, использующих пространство имен оболочки (например, стандартное диалоговое окно "Открыть файл"), поскольку оболочка обрабатывает символические ссылки, как если бы они были ярлыками, даже до точки изменения отображаемого значка. Было ли это разумным решением со стороны Microsoft, на данном этапе это спорный вопрос, так как он не собирается меняться. Насколько я знаю, это не настраивается.

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

Итак, ваши первые два примера (способ, которым Explorer отображает файлы и поведение Notepad++), являются скорее функциями, чем ошибками; нравится вам это или нет, но так Windows работает.

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

---

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

Answer 2

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

Они могут пройти FILE_FLAG_OPEN_REPARSE_POINT в CreateFileили быть слишком агрессивным при "проверке" атрибутов файла и подавлении FILE_ATTRIBUTE_REPARSE_POINT,

В вашем конкретном случае, я предполагаю, что расширенный редактор должен использовать FOS_NODEREFERENCELINKS в их открытом диалоге. Переключатель CSS может использовать FILE_FLAG_OPEN_REPARSE_POINT и вы сможете проверить это с помощью Process Monitor.

Там нет волшебной записи реестра, которую вы можете использовать, вы должны связаться с авторами приложения.

Answer 3

Файл - это указатель на определенный узел.

Когда вы создаете жесткую ссылку, вы просто создаете новый файл, который указывает на тот же узел, что и исходный файл.

Когда вы создаете мягкую ссылку, вы делаете не указатель на узел, а на файл. Из-за этой мягкой ссылки разрешается путь к файлу, на который она указывает.

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