New-Item Type SymbolicLink on Unix-like platforms unexpectedly converts relative target paths to absolute one #15233
Description
PR #12797 tried to implement support for relative target paths for symbolic links (symlinks).
-
On Windows, this now works properly.
-
On Unix-like platforms, a relative input path is still unexpectedly converted to a full path and stored as such in the symlink.
Steps to reproduce
Note: Run on macOS and/or Linux (the test succeeds on Windows).
Push-Location -ea Stop ($tmpDir = (New-Item -Type Directory -Force (Join-Path Temp:/ $PID)).FullName)
# Create a file to serve as the symlink target.
$null = New-Item -Force file
# Determine the native file-system path separator, as well as the one
# *not* native to the platform.
$sep = [IO.Path]::DirectorySeparatorChar
$otherSep = $sep -eq '/' ? '\' : '/'
# To also test path-separator normalization, we use the non-native separator.
$null = New-Item -Force -Type SymbolicLink fileL -Target ".${otherSep}file"
# The symlink's target should be a relative path that uses the platform-appropriate path separator.
(Get-Item fileL).Target | Should -Be ".${sep}file"
# Clean up.
Pop-Location; Remove-Item $tmpDir -RecurseExpected behavior
The test should succeed.
Actual behavior
The test fails, because the relative input path is unexpectedly first resolved to a full path before the symlink is defined:
InvalidResult: Expected strings to be the same, but they were different.
Expected length: 6 Actual length: 14 Strings differ at index 0.
Expected: './file' But was: '/tmp/2802/file'
Environment data
PowerShell Core 7.2.0-preview.4