Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registry provider: key names "." and ".." aren't supported in PS drive paths due to filesystem-like path normalization #9451

Closed
mklement0 opened this issue Apr 23, 2019 · 6 comments
Labels
Area-FileSystem-Provider specific to the FileSystem provider Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-No Activity Issue has had no activity for 6 months or more WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

Comments

@mklement0
Copy link
Contributor

mklement0 commented Apr 23, 2019

If you use a path with a key literally named . or .. that is based on one of the registry drive provider's drives such as HKCU:, these names are currently misinterpreted as referring to the current and parent "directory" respectively, as in the filesystem.

The workaround is to use a provider-native path via the registry:: prefix.

If it's too late to change this behavior and perhaps people rely on it, expecting filesystem-analogous behavior, the pitfall - and workaround - should be documented.

Note that creating a key named . is not a hypothetical example; you need it to define a file type for extension-less file names, for instance (HKEY_CLASSES_ROOT\.)

Steps to reproduce (on Windows)

Note: The same applies analogously to a key literally named '..'.

# A path to a key named "."
$regPathPS = 'HKCU:\_tmp\.'
# Equivalent provider-native path.
$regPathProviderNative = 'registry::HKEY_CURRENT_USER\_tmp\.'

# Create the key using the provider-native path
# - which is currently the only option.
$null = New-Item -Force $regPathProviderNative

# Try to retrieve the new key using the PS drive notation.
# This currently retrieves 'HKCU:\_tmp' instead, i.e., the
# *parent* path, because the "." is misinterpreted as a reference to
# the "directory" HKCU:\_tmp
try {

  (Get-Item -LiteralPath $regPathPS).PSChildName | Should -Be '.'

} finally {
  # Clean up.
  Remove-Item -Recurse -LiteralPath (Split-Path -Path $regPathPS)
}

Expected behavior

The test should pass.

Actual behavior

The test fails:

...
Strings differ at index 0.
Expected: '.'
But was:  '_tmp'
...

Environment data

PowerShell Core 6.2.0 / Windows PowerShell v5.1
@mklement0 mklement0 added the Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a label Apr 23, 2019
@iSazonov iSazonov added the WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc. label Apr 24, 2019
@kvprasoon
Copy link
Contributor

Is the problem is in Get-Item ? It get the proper childname using Get-ChildItem

@mklement0
Copy link
Contributor Author

@kvprasoon, no: Get-ChildItem is equally affected.

It only works incidentally in this scenario: it still targets only registry::HKEY_CURRENT_USER\_tmp and enumerates its children - the only one of which happens to be . in the test above; if you create a sibling key, say, registry::HKEY_CURRENT_USER\_tmp\foo, you'll see that Get-ChildItem HKCU:\_tmp\. enumerates them both.

@iSazonov iSazonov added the Area-FileSystem-Provider specific to the FileSystem provider label Dec 1, 2021
Copy link
Contributor

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.

2 similar comments
Copy link
Contributor

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.

Copy link
Contributor

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 microsoft-github-policy-service bot added Resolution-No Activity Issue has had no activity for 6 months or more labels Nov 16, 2023
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-FileSystem-Provider specific to the FileSystem provider Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-No Activity Issue has had no activity for 6 months or more WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
Projects
None yet
Development

No branches or pull requests

3 participants