问题描述
用户具有读取共享的适当权限，并且共享映射正确.此问题似乎仅在 PowerShell v2.0 中发生.
The user has appropriate permissions to read the share, and the share maps properly.This issue seems to happen only in PowerShell v2.0.
如果我删除所有映射的驱动器，重新映射一个驱动器，然后运行测试路径:
If I remove all mapped drives, remap one drive, and run Test-Path:
net use /delete * /y
net use G: \\somefileserver\share
Test-Path G:\
Test-Path 返回 False，即使驱动器已明确映射，并且我可以通过 Windows 资源管理器访问它.
Test-Path returns False, even though the drive is clearly mapped, and I can access it through Windows Explorer.
如果我关闭 PowerShell 会话并打开一个新会话，Test-Path 将返回 True，它应该如此.关于(A)的任何想法:什么可能导致这种情况，以及如何使其正常工作?或 (B): 除了 Test-Path 之外，还有其他方法可以测试网络驱动器的存在吗?我正在尝试编写一个登录脚本来映射用户的网络驱动器，这种行为让我发疯.
If I close the PowerShell session, and open a new session, Test-Path returns True, as it should. Any ideas on, (A): what could be causing this, and how do I make it work properly? or (B): Is there another way to test for the existence of a network drive besides Test-Path? I am attempting to write a logon script to map user's network drives and this behavior is driving me insane.
推荐答案
如果 Test-Path cmdlet 确实有问题，那么我建议使用 Exists() System.IO.Directory .NET 类上的方法.
If the Test-Path cmdlet is truly buggy, then I'd suggest using the Exists() method on the System.IO.Directory .NET class.
[System.IO.Directory]::Exists('G:\'); # This returns $true for me
这篇关于PowerShell 测试路径在测试网络共享时返回 False的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！