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

@iSazonov Please have a look at the test failure

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

@iSazonov Thank you for your contribution!

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

Handy links:

• Release Notes

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

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

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

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

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