Fix New-Item to create symlink to relative path target

[iSazonov]

PR Summary

Fix #9127.

Before the fix we check an item existence relative to system CWD. After the fix we do the check based on current runspace CWD.

PR Context

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• 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.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• 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
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[vexx32]

@iSazonov thanks for taking the time to sort this one out. 😊

Quick question -- should / will this affect the -ItemType Junction / -ItemType Hardlink modes for New-Item and should we be testing those here as well?

[adityapatwardhan]

@iSazonov Please have a look at the test failure

[iSazonov]

@mklement0 Could you please help with the MacOs fail? Do you have any thoughts?

[adityapatwardhan]

@iSazonov Thank you for your contribution!

[ghost]

🎉v7.1.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes

[MatejKafka]

Is this really how relative path for symlink should behave? This PR changes the behavior of the checks from having -Target relative to .NET CWD to PowerShell CWD, but it's still inconsistent with how filesystem actually resolves the symlink.

Relative path in the symlink target is resolved by filesystem relative to the directory containing the symlink, not relative to CWD of pwsh instance that created it.

---

This should create a working directory symlink:

mkdir ./test
mkdir ./test/dir
ni -Type SymbolicLink ./test/dir_link -Target ./dir

Instead, the check uses path relative to current working directory (./dir) instead of relative to symlink path (./test/dir).

[iSazonov]

@MatejKafka Please create new issue if you see an inconsistency.

[mklement0]

@MatejKafka, while you are correct, this problem doesn't currently surface, although there are related ones:

With respect to creating the symlink, i.e. what target path is stored in its definition:

• On Windows, the relative path is stored as-is (excepting possible path-separator normalization) in the new symlink - which is indeed what should happen.

  • However, a relative path that starts with a name rather than .\ causes problematic behavior with Get-ChildItem - see On Windows, a directory symlink doesn't behave a like a directory with Get-ChildItem if its target path is a relative path that starts directly with a name #15161.

• On Unix-like platforms, unexpected resolution to a full path happens before the symlink is created, which is a bug, and was reported in New-Item Type SymbolicLink on Unix-like platforms unexpectedly converts relative target paths to absolute one #15233.

With respect to validating the existence of the target path on creation:

• This validation - which should indeed happen relative to the symlink's location - is currently broken on all platforms, so that targeting a non-existing path is quietly possible, with the exception of using full paths with non-existent drive names / UNC paths.

  • While this is sometimes desired, it should be an opt-in, and on Windows presents the additional challenge of then needing to specify whether the hypothetical future target is a file or a directory.

  • See New-Item symlinks cannot be created if destination (target) is non-existent or not accessible #9067 (comment)

[MatejKafka]

@mklement0 Actually, I think it currently surfaces. Because the checks are relative to cwd, they incorrectly detect whether the target is file or directory. Let me try to illustrate it with more examples:

(I'll use D:\test as our testing directory to make it clear when I'm talking about absolute paths)

mkdir D:/test
mkdir D:/test/dir
ni -Type SymbolicLink D:/test/dir_link -Target ./dir

Expected: directory symlink to D:/test/dir, with target ./dir
Got: file symlink to D:/test/dir, with target ./dir
The target type detection code checks the relative path ./dir (D:/dir), which doesn't exist, so the symlink incorrectly defaults to file symlink.

mkdir D:/test
mkdir D:/test/dir
cd D:/test
ni -Type SymbolicLink D:/test/dir_link -Target ./dir

Expected: directory symlink to D:/test/dir, with target ./dir
Got: what I expected
Only difference from previous example is the cd D:/test. This correctly creates a directory symlink, because the code checks type of target for ./dir (D:/test/dir), which now matches the real target.

mkdir D:/test/subdir
mkdir D:/test/item # <-- directory
ni D:/test/subdir/item # <-- file
cd D:/test
ni -Type SymbolicLink D:/test/subdir/item_link -Target ./item

Expected: file symlink to D:/test/subdir/item, with target ./item
Got: directory symlink D:/test/subdir/item, with target ./item
The the file D:/test/item is used for target check, it's a directory, so a directory symlink is created (but the actual target is D:/test/subdir/item, which is a file).

---

There are 2 possible correct behaviors I see here:

1. Set absolute path as a symlink target, and resolve the target path to be absolute. This effectively prevents PowerShell from creating symlinks with relative paths to target, but still solves this issue.
2. Allow relative paths, but when checking for target type (file/directory), use the path Join-Path $Path $Target internally, but still write $Target as provided by user (relative) into the symlink itself. This is imo the better solution, allows the user to create symlinks with relative paths, but still correctly detects the type.

[mklement0]

Good point, @MatejKafka. As @iSazonov has advised, please create a new issue with your findings.