Note: This is ultimately a duplicate of #15235
PR #8783 brought the ability to use relative paths as symlink targets on Windows.
However, if the target is a directory and the relative path starts with / is just a name (rather than starting with .\), the resulting symlink doesn't behave like a directory with Get-ChildItem.
Note that on Unix, as of PowerShell Core 7.2.0-preview.4, use of relative target paths is still fundamentally unsupported - see #15233
Steps to reproduce
Run on Windows:
# Switch to a temporary directory.
Push-Location -ea Stop ($tmpDir = (New-Item -Type Directory -Force (Join-Path Temp:/ $PID)).FullName)
# Create a dir. to serve as the target, with a single text file in it.
$null = New-Item -Type Directory target -Force
'hi' > target/t.txt
# Define two links:
# * one that targets 'target' - by name only.
# * one that targets '.\target' - explicit reference to the current dir.
$null = New-Item -Type SymbolicLink link1 -Target target -Force
$null = New-Item -Type SymbolicLink link2 -Target .\target -Force
# Now compare the Get-ChildItem behavior of these two links, which
# *should* be the same.
Get-ChildItem link1
Get-ChildItem link2
Pop-Location; Remove-Item -lp $tmpDir -Recurse
Expected behavior
With the exception of the directory path in the grouping header, the commands should produce the same output and show the content of the target dir:
Directory: C:\Users\jdoe\AppData\Local\Temp\8748\link1
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 4/5/2021 3:30 PM 4 t.txt
Directory: C:\Users\jdoe\AppData\Local\Temp\8748\link2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 4/5/2021 3:30 PM 4 t.txt
Actual behavior
Directory: C:\Users\jdoe\AppData\Local\Temp\8748
Mode LastWriteTime Length Name
---- ------------- ------ ----
la--- 4/5/2021 3:30 PM 0 link1 -> target
Directory: C:\Users\jdoe\AppData\Local\Temp\8748\link2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 4/5/2021 3:30 PM 4 t.txt
Note how link1 present as if it were a flle, as if you had called Get-Item rather than Get-ChildItem on it.
Interestingly, cmd.exe's dir shows analogous behavior, and additionally fails with dir link1\t.txt, which PowerShell handles correctly.
Environment data
PowerShell Core v7.2.0-preview.4 (.NET 6.0.0-preview.2.21154.6) on Microsoft Windows 10 Pro (64-bit; Version 20H2, OS Build: 19042.867)
Note: This is ultimately a duplicate of #15235
PR #8783 brought the ability to use relative paths as symlink targets on Windows.
However, if the target is a directory and the relative path starts with / is just a name (rather than starting with
.\), the resulting symlink doesn't behave like a directory withGet-ChildItem.Note that on Unix, as of PowerShell Core 7.2.0-preview.4, use of relative target paths is still fundamentally unsupported - see #15233
Steps to reproduce
Run on Windows:
Expected behavior
With the exception of the directory path in the grouping header, the commands should produce the same output and show the content of the target dir:
Actual behavior
Note how
link1present as if it were a flle, as if you had calledGet-Itemrather thanGet-ChildItemon it.Interestingly,
cmd.exe'sdirshows analogous behavior, and additionally fails withdir link1\t.txt, which PowerShell handles correctly.Environment data