Enable creating relative symlinks with New-Item - #8783

Codefactor issues are on untouched code and incorrectly identifying Hungarian notation

FileSystem.Tests.ps1 failed in all 3 CI systems.
This looks suspicious considering that the change is in SessionStateContainer.cs. :)

Looking

The spelling error in static analysis is unrelated to this PR. The CodeFactor issues are also unrelated to the changes in this PR.

Andrew (@anmenaga) I believe this is ready to merge

I'd like to see sign offs from Ilya (@iSazonov) and Rain Sallow (/u/ta11ow) (@vexx32) .

I have only one open question above.

Steve Lee (@SteveL-MSFT):

Thanks for fixing this.

On non-Windows, the relative path is passed to the symlink() api which ends up creating an absolute link.

I just tried the new code on my Mac, and it was able to create a symlink with a relative path just fine.

Using the ln command line tool has the same result.

Similarly, ln on macOS and Linux creates symlinks with relative target paths, if given a relative path.
In fact, that's the typical use case.

I suggest enabling the tests for Unix-like platforms too.

Michael Klement (@mklement0) I tried it on my macBook and it didn't create a relative link. Not sure why it's different for me as the tests failed on my system and was also failing in CI.

Steve Lee (@SteveL-MSFT):

To verify that ln is capable of creating relative symlinks on both macOS and Linux, run the following test:

Describe "Relative symlink path test" {
  It "ln creates a symlink with a relative path when given one" {
    ln -s . /tmp/$pid
    readlink /tmp/$pid | should -BeExactly '.'
    rm /tmp/$pid
  }
}

Steve Lee (@SteveL-MSFT), inferring the correct symlink type on Windows seems to be broken with relative paths to existing directories - see #9127

On a related note, we must come up with a way to explicitly specify the target type for nonexistent (not-yet-extant) targets - see #9067 (comment)