Попробуйте создать ссылку на \\servername\sharename\Public\Quick Books Data\Finance Drive вместо подключенного диска Q:, На моей Windows 7 x64, оказывается, оба метода работают, однако.
Также убедитесь, что вы установили сеанс с удаленным сервером (проверьте с помощью net use ) если только это не общий ресурс Windows, который не требует учетных данных.
Кроме того, убедитесь, что ACL установлены правильно по символической ссылке сам с icacls /L, Запуск без /L не даст ожидаемых результатов. Это требует прав администратора так же, как создание символической ссылки.
Изменить 1:
Вопреки тому, что я написал в более ранней редакции этого ответа, выясняется, что объект и менеджер ввода-вывода способны понимать подключенные сетевые диски (ищите \Device\LanManRedirector символические ссылки в WinObj под одним из каталогов объектов ниже \Sessions\0\DosDevices ). Только что проверил.
Я также посмотрел это в Windows Internals, 5th edition, Russinovich et al. (страницы 924 и далее), потому что вы меня заинтересовали. Вы можете проверить с fsutil behavior query SymLinkEvaluation как символические ссылки настроены в вашей системе. По умолчанию будет (также на Vista SP2):
>fsutil behavior query SymLinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.
Только что проверил, что он работает для символической ссылки на UNC-путь или букву подключенного диска, если ACL правильно установлен на общем ресурсе, а также на символической ссылке. Однако установка слишком ограничительного списка ACL для символической ссылки приведет к сбою.
Я проверил это как для старого стиля а также тот, который требует учетных данных (в моем случае на домене, в то время как я не на этом домене).
Для получения списка ACL используйте:
icacls <symlink-name> /L
Тем не менее, я также тестировал на Vista SP2 x64 только сейчас, и я столкнулся с проблемой, с которой вы столкнулись если Я использую букву диска в качестве пути назначения, хотя политика оценки символических ссылок установлена так же, как для Windows 7 SP1 x64, на которой я тестировал.
Изменить 2:
В WinDbg я отслеживал, что происходит. Я сначала решил проверить mup водитель, которого я знаю, владеет LanManRedirector среди других объектов устройства. Моим отладчиком ядра была Vista SP2, которая подвергаются такое же поведение вы видите.
Первым делом я создал карту сетевого диска L: в \\server\share а затем две символические ссылки: C:\Users\user\drv-name указывая на L:\\ а также C:\Users\user\unc-name указывая на \\server\share,
Зная, что символические ссылки являются точками повторной обработки, я решил перечислить все функции драйвера NTFS ( dt ntfs!* -v ) и выберите наиболее перспективные для установки точек останова на:
kd> bp Ntfs!NtfsGetReparsePoint
kd> bp Ntfs!NtfsReparsePointName
kd> bp Ntfs!NtfsInitializeReparseFile
kd> bp Ntfs!_imp_FsRtlValidateReparsePointBuffer
kd> bp Ntfs!NtfsReparsePointString
kd> bp Ntfs!NtfsCreateReparsePointInternal
kd> bp Ntfs!NtfsGetReparsePointValue
конечно, пренебрегая тем, что драйверы файловой системы - очень деликатная вещь. О чем Windows напомнила мне настойчивой проверкой ошибок 0x24,
К сожалению, после того, как система снова заработала, обе символические ссылки работали даже на той виртуальной машине Vista SP2. Это означает, что у меня нет возможности воспроизвести проблему каким-либо последовательным образом. Это значит, что я пока не могу копать глубже.
Junction "C:\FinanceDrive2" "Q:\Public\Quick Books Data\Finance Drive"