Enable creating relative symlinks with New-Item

[SteveL-MSFT]

PR Summary

The current code always tries to glob the target path which results in an absolute path and limits the usefulness of creating a symlink. Fix is to see if the target path even contains any wildcards, if not, don't use the resolved globbed path and instead use the value as literal. Since there isn't a -LiteralTarget parameter, this does mean that the globber can fail if the target path contains a wildcard character intended to be literal, but that is not in scope of this PR.

Note that relative links are only supported on Windows so skipping test on non-Windows. On non-Windows, the relative path is passed to the symlink() api which ends up creating an absolute link. Using the ln command line tool has the same result.

PR Context

Fix #3500

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
    • Add [feature] to your commit messages if the change is significant or affects feature tests

[SteveL-MSFT]

Codefactor issues are on untouched code and incorrectly identifying Hungarian notation

[anmenaga]

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

[SteveL-MSFT]

Looking

[SteveL-MSFT]

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

[SteveL-MSFT]

@anmenaga I believe this is ready to merge

[anmenaga]

I'd like to see sign offs from @iSazonov and @vexx32 .

[iSazonov]

I have only one open question above.

[iSazonov]

LGTM with one minor comment.

[vexx32]

Nothing I can see that hasn't already been mentioned; looks good! 🙂

[mklement0]

@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.

[SteveL-MSFT]

@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.

[mklement0]

@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
  }
}

[mklement0]

@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)