Windows 10 и проблемы с символьными ссылками

Question

У меня есть конфигурация двойной загрузки, состоящая из Windows 7 и Windows 10. Оба настроены как диск C: как система, а диск D: как диск с данными, в который входит каталог Users. И у меня есть еще один (физический тоже!) диск, назовем его V:, с фотографиями и прочим.

В Windows 7 для доступа к фотографиям с диска D: я сделал символическую ссылку (соединение), как это (исторические причины):

mklink /j d:\photos v:\photos

И я могу полностью получить доступ ко всем папкам в d:\photos. Поэтому я попытался сделать то же самое в Windows 10, но он не работает должным образом. Я могу ввести d:\photos, но другой подкаталог недоступен, и ничего не могу написать внутри d:\photos. Но я могу получить доступ к v:\photos без проблем ...

Если я нажму с Windows Explorer для, например,. d:\photos\folder1, я получаю сообщение "Система не может переместить файл на другой диск". Если я проверяю вкладку безопасности в этой папке, я нахожу сообщение «Запрошенная информация о безопасности либо недоступна, либо не может быть отображена».

Я уже попробовал несколько вещей, но безуспешно. Может быть проблема в том, что C: и D: находятся на одном SSD, а V: это другой HD? Есть идеи что делать?

Спасибо!

Answer 1

Хотя соединения поддерживаются на локальных дисках, вам, вероятно, повезет больше с реальными символическими ссылками на каталоги. Win7 (все, начиная с Vista, в частности) поддерживает их, а XP и более ранние - нет. Символьные ссылки хранят фактические имена получателей (поэтому, если на другом диске указан V: в обеих ОС он должен работать). Мое предположение состоит в том, что узлы могут использовать идентификатор, отличный от буквы диска, и когда вы переключаете ОС, некоторые из этих идентифицирующих данных не понимаются другими ОС. Очевидно, они не просто используют имя, иначе вы сможете соединиться с подключенным сетевым диском, а вы не сможете.

Синтаксис для создания истинной символической ссылки для каталога такой же, как и для создания соединения, за исключением того, что используется флаг /D для mklink , а не /J Обратите внимание, что по умолчанию только администраторы могут создавать символические ссылки (не уверены, почему это применяется для символических ссылок, а не для соединений, но c'est la vie). Итак, запустите командную строку от имени администратора (и да, это должен быть CMD ; mklink - это встроенный CMD, а не собственный исполняемый файл, который может быть вызван, скажем, Powershell) и попробуйте mklink /d d:\photos v:\photos ,

Обратите внимание, что вы также можете использовать mklink без каких-либо флагов для создания символических ссылок файлов или с флагом /H для создания жестких ссылок файлов. Здесь не актуально, так как вы пытаетесь связать каталоги, а не файлы, но потенциально полезную информацию на будущее. Большинство людей не знают, что NTFS поддерживает жесткие ссылки (так как ... Windows 2000, я думаю?) и символические ссылки (начиная с Vista), даже если они знают о соединениях (которые не совсем полные символические ссылки, или вы могли бы создать их на сетевой диск).

Answer 2

У меня была такая же проблема; кажется, это вызвано изменением места установки приложений на другой диск.

Для меня это решило, установив место сохранения новых приложений обратно в C, а затем перезагрузившись в командную строку (удерживая нажатой клавишу shift при перезапуске) и удалив «System Volume Information\wpappsettings.dat» на рассматриваемом диске.

Answer 3

Имеет ту же проблему: имеет диск C:(новый windows10) D:(старый) E:(старый)

Я могу создать соединение каталогов от D до C (для подпапок "Program Files" и т.д.), Но не могу сделать то же самое от E до D: соединения созданы, но я не вижу содержимое файлов и подпапок с той же ошибкой.

Не понимаю почему, но все решается загрузкой Ubuntu и удалением «D:\System Volume Information» (он был воссоздан Win10 после).

PS. Имеет нормальный результат fsutil behavior query symlinkevaluation: локально к * включен, удаленно к * отключен

Answer 4

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

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