Looks like you are mixing up two different things: PowerShell path and Provider path. PowerShell paths are not visible outside of PowerShell.
New-PSDrive X FileSystem C:Windows
(Get-Item X:System32
otepad.exe).get_Length() #OK
([IO.FileInfo]'X:System32
otepad.exe').get_Length() #Error
But Get-Item X:System32
otepad.exe
managed to create a FileInfo
object, which represents some file. So, what file is represented by the resulting FileInfo
object?
(Get-Item X:System32
otepad.exe).FullName
# C:WindowsSystem32
otepad.exe
Since the FileInfo
object knows nothing about PowerShell drive X:
, it has to store a path, which internally uses the file system API which it can understand. You can use Convert-Path
cmdlet to convert PowerShell path to Provider path:
Convert-Path X:System32
otepad.exe
# C:WindowsSystem32
otepad.exe
Same happens when you create the PowerShell drive, which point to some network path:
New-PSDrive Y FileSystem \ComputerShare
Get-ChildItem Y:
Returned FileInfo
and DirectoryInfo
objects know nothing about Y:
, so they can not have paths relative to that PowerShell drive. Internally used file system API will not understand them.
Things changes when you use the -Persist
option. In that case real mapped drives will be created, which can be understood by file system API outside of PowerShell.
New-PSDrive Z FileSystem \ComputerShare -Persist|Format-Table *Root
# Root : Z:
# DisplayRoot : \ComputerShare
As you can see, the Root
will be not \ComputerShare
as you ask in New-PSDrive
cmdlet, but Z:
. Since Z:
is a real drive in this case, FileInfo
and DirectoryInfo
objects returned by Get-Item
or Get-ChildItem
cmdlet can have paths relative to it.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…