У меня конфигурация двойной загрузки, состоящая из 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, например, d:\photos\folder1, я получаю сообщение «Система не может переместить файл на другой диск». Если я проверяю вкладку безопасности в этой папке, я нахожу сообщение «Запрошенная информация о безопасности либо недоступна, либо не может быть отображена».
Я уже пробовал несколько вещей, но безуспешно. Может быть проблема в том, что C: и D: находятся на одном SSD, а V: - это другой HD? Есть идеи, что делать?
Спасибо!
решение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), даже если они знают о соединениях (которые не являются полной символической ссылкой, или вы можете создать ее на сетевом диске).
решение2
У меня была та же проблема; похоже, она была вызвана изменением места установки приложений на другой диск.
Для меня проблема решилась установкой места сохранения новых приложений обратно на диск C, а затем перезагрузкой в командной строке (удерживайте клавишу Shift при перезагрузке) и удалением «System Volume Information\wpappsettings.dat» на соответствующем диске.
решение3
Та же проблема: есть диск C:(новый windows10) D:(старый) E:(старый)
Я могу создать соединение каталогов из D в C (для подпапок «Program Files» и т. д.), но не могу сделать то же самое из E в D: соединения создаются, но я не вижу содержимого файлов и подпапок с той же ошибкой.
Не понимаю почему, но все решилось загрузкой Ubuntu и удалением «D:\System Volume Information» (он был воссоздан Win10 позже).
PS. Имеет нормальный результат fsutil behavior query symlinkevaluation: local-to-* включен, remote-to-* выключен
решение4
Я столкнулся с похожей проблемой некоторое время назад, которая была вызвана системой разрешений. В моем случае у меня был unc-path в качестве цели, разрешения и общий доступ были настроены правильно. В unc-path я мог создавать ссылки и погружаться в подпапки, в символической папке — нет. Наследование прав от верхних папок было причиной.
Попробуйте отключить наследование разрешений для символической папки и удалить разрешения, которые могут вызвать проблемы. Установите явные разрешения, чтобы получить полный контроль над символической папкой. В моем случае это решило проблемы, и я смог создавать ссылки и погружаться в подпапки.