Join-Path doesn't handle provider prefixes correctly on Unix-like platforms

[mklement0]

Steps to reproduce

On macOS or Linux:

Join-Path (Get-Item .).PSParentPath foo | Should -Be "$((Get-Item .).PSParentPath)/foo"

Expected behavior

The test should succeed.

Actual behavior

The test fails, because the existing provider prefix isn't recognized as such, causing its \ separator to be normalized to / and another provider prefix to be prepended.

Expected strings to be the same, but they were different. Expected length: 65 Actual length:   103 Strings differ at index 38. Expected: '...tem::/User...' But was:  '...tem::Micro...'

That is, Join-Path's output was something like (note the doubled provider prefix, with the 2nd one using /):

Microsoft.PowerShell.Core\FileSystem::Microsoft.PowerShell.Core/FileSystem::/Users/jdoe/Desktop/foo

Environment data

PowerShell Core 7.2.0-preview.2

[iSazonov]

Is this for Linux and MacOs only?

[mklement0]

@iSazonov, yes, because the problem is related to normalizing \ to /.

[ghost]

Hi folks. Is this up for grabs? If so, I'd like to take it on.

[ghost]

@iSazonov, resurfacing my question above. This issue is not tagged as up for grabs but I'm wondering whether it could still be a good one for me to look into.

[vexx32]

@octos4murai I haven't seen anyone else wanting to take it up, and it seems a fairly clear case of the behaviour being bugged, so yeah, we may as well consider it up for grabs. 🙂

[ghost]

I've been able to take a better look and wanted to ask a couple questions before I start writing any code:

• Is it intentional for the FileSystemProvider to have a Windows-style path separator (\) in Unix-like platforms? For example, Microsoft.PowerShell.Core\FileSystem::/Users/jdoe/Desktop/foo instead of Microsoft.PowerShell.Core/FileSystem::/Users/jdoe/Desktop/foo. It appears this is hardcoded in ProviderNames.FileSystem.
• Assuming the answer to the question above is yes, could an ideal fix be to exclude the FileSystemProvider string from any normalization? Potentially a good place to make this change is NavigationProviderBase.NormalizePath(string path).

[iSazonov]

FileSystem Provider always normalizes paths. See

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

Lines 103 to 106 in 3733a0b

	private static string NormalizePath(string path)
	{
	return GetCorrectCasedPath(path.Replace(StringLiterals.AlternatePathSeparator, StringLiterals.DefaultPathSeparator));
	}

.

[ghost]

Thanks for your response @iSazonov -- but allow me to switch gears for a bit... Is Join-Path even meant to have support for paths prepended with the FileSystemProvider prefix? This page does not give any hints that it is supported behaviour: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/join-path?view=powershell-7.1.

A supported way to accomplish @mklement0's example above is to do this instead:

Join-Path (Get-Item .).Parent.FullName foo
# Returns something like: /home/octos4murai/foo

Unless I'm missing something, this should be classified as an enhancement (if it's decided it should be supported at all).

Join-Path (Microsoft.PowerShell.Management) - PowerShell

The Join-Path cmdlet combines a path and child-path into a single path. The provider supplies the path delimiters.

[iSazonov]

Is Join-Path even meant to have support for paths prepended with the FileSystemProvider prefix?

Yes, it is. All paths on top level is PowerShell paths (provider qualified paths). Then on level below they are resolved to provider specific paths.

Root of the issue is in broken normalization \ to / .

[ghost]

Thanks! For the following command in Unix-like systems:

Join-Path (Get-Item .).PSParentPath foo

Which of the following is the expected result:

Microsoft.PowerShell.Core/FileSystem::/home/octos4murai/foo

or

Microsoft.PowerShell.Core\FileSystem::/home/octos4murai/foo

I assume it's the first one with consistent path separators?

[iSazonov]

Provider names are never normalized. You can find them in SingleShellProviderNames class.
In your example this is Microsoft.PowerShell.Core\FileSystem::/home/octos4murai/foo.
Changing this will be huge breaking change.
Notice - they is names.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.