Попробуйте создать ссылку на \\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: to \\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
конечно, пренебрегая тем, что драйверы файловой системы - очень деликатная вещь. О чем Виндос напомнил мне настойчивой проверкой 0x24 .
К сожалению, после того, как система снова заработала, обе символические ссылки работали даже на той виртуальной машине Vista SP2. Это означает, что у меня нет возможности воспроизвести проблему каким-либо последовательным образом. Это значит, что я пока не могу копать глубже.
