PR #12797 tried to implement support for relative target paths for symbolic links (symlinks).

On Windows, this now works properly as of PowerShell Core 7.1.0-preview.4, including normalizing path separators to \.

On Unix-like platforms, a relative input path is still unexpectedly converted to a full path and stored as such in the symlink.

Curiously that doesn't happen when you use \ as a separator on macOS - which must be normalized to / on Unix-like platforms - but the normalization doesn't happen and the \-based relative path is stored as-is, which results in a broken symlink; on Linux, the unexpected conversion to an absolute path (with appropriate separators) takes place.

Steps to reproduce

# OK on Windows, FAILS on macOS and Linux.
Describe "New-Item symlinks" {
  BeforeAll {
    Push-Location testdrive:

    $targets = "./$PID.tmp", ".\$PID.tmp"
    $lnk = "$PID-L.tmp"

    'foo' > $targets[0]

  }

  It "Can create symlink with relative target <target>" -TestCases @{ target = $targets[0] }, @{ target = $targets[1] } {
    param([string] $target)

    $null = New-Item -Type SymbolicLink  $lnk -Target $target  -Force

    # Make sure the relative target path was recorded as such and uses
    # the platform-appropriate separator.
    (Get-Item $lnk).Target | Should -Be ($target -replace '[\\/]', [IO.Path]::DirectorySeparatorChar)

  }

  AfterAll {
    Pop-Location
  }
}

Expected behavior

The tests should succeed on all platforms.

Actual behavior

On macOS and Linux, both tests fail:

The first test fails, because the relative path was converted to an absolute one.

      Expected: './95916.tmp'
      But was:  '/private/t...'

On macOS, the second test fails because \ wasn't normalized to /:

      Expected: './95916.tmp'
      But was:  '.\95916.tmp'

On Linux, by contrast, the test fails because the relative path is again unexpectedly converted to an absolute one.

Environment data

PowerShell Core 7.1.0-preview.4