Enable New-Item creates symlinks to non-existent targets

[iSazonov]

PR Summary

Fix #9067.
Fix #13064.
Fix #13136.

1. Ignore exception if target path can not be resolved (is not exist) and consider it as literal (only first slash is normalized).
2. Create symlink in the case only if -Force switch presents.

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

[iSazonov]

@mklement0 Could you please review and try this? I hope this address your requests.

[mklement0]

This doesn't help, because the relative content path is ultimately still normalized in

PowerShell/src/System.Management.Automation/namespaces/FileSystemProvider.cs

Line 2379 in 90c7ed6

normalizedTargetPath = Path.Join(SessionState.Internal.CurrentLocation.ProviderPath, strTargetPath.AsSpan().Slice(2));

- at least when I debug on macOS. Note that the relative path mustn't be used as-is: you must perform the equivalent of $relativePath -replace '[\\/]', [IO.Path]::DirectorySeparatorChar to normalize the separators.

[mklement0]

Also, on a general note: I don't think it makes sense to ever interpret the target path as a wildcard pattern - see #13136

[iSazonov]

Do you say about existent targets? In the case it is another issue. I don't change the behavior in the PR. I only address non-existent targets.

[mklement0]

Yes, this is about existing targets (too), as described in #13064, which your PR description notes as targeting (in addition to #9067); also, the need to normalize the path separators in relative paths applies to both existing and non-existing targets.

I'd say it makes sense to fix all these things together, but if you don't want to do that, please at least remove #13064 from the PR description.

[iSazonov]

I do not think that we can normalize non-existing targets safely. We can get unexpected results and can not check the targets.

[mklement0]

I'm still confused: I also don't see why the .Target property shouldn't just use the target path as defined.
What reason is there to try to interpret it in any way?

[iSazonov]

It seems we say about different things.
Currently if we create a symlink with relative path the Target property will return absolute path but we expect a relative path used at creation time. Because of this one test fails in the PR on Unix-s.

[mklement0]

I pulled your PR, built it on macOS 10.15 and Ubuntu 18.04 and can confirm that it correctly creates symlinks with relative paths and performs separator normalization (and that .Target currently always reports the full path, assuming the target exists).

I'm still a bit confused about the .Target property: on Windows, it seemingly reports the target path as stored in the link. Why did we ever resolve it to a full path on Unix?

So your plan is to later change that and make it behave like it does on Windows?
But then you wouldn't need a call to realpath() at all, right?

Separately, knowing the full, resolved path is also useful, so we could consider adding a .ResolvedTarget property that always reports the full path, if it exists. For non-symlink items, it could report that item's own full path, which would enable you to target items uniformly by their ultimate target path.

[iSazonov]

@mklement0 Thanks!

So your plan is to later change that and make it behave like it does on Windows?
But then you wouldn't need a call to realpath() at all, right?

Yes, we should open new issue to track this.

Separately, knowing the full, resolved path is also useful

Please open new issue to discuss.

[mklement0]

See #13365 and #13366.

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

[vexx32]

If we need to mark this It as pending, we may want to separate the assertions into two separate tests.

Otherwise, the result will be confusing from this test (it might fail sometimes, but at most it will only be Pending in Mac/Linux).

Also, the cmdlet name is misspelled here. 🙂

[iSazonov]

@vexx32 Thanks! I split tests.

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

[SteveL-MSFT]

You should add a test case to cover this

[iSazonov]

It is not new code. It is moved code.

[SteveL-MSFT]

I don't understand the use of the wildcardpattern here, type is a string for filesystem that should be symboliclink, junction, hardlink, etc... right? why isn't this a switch statement?

[iSazonov]

It is not new code. It is moved code.