-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
Bug: can not handle "/" correctly when reading registry item #5536
Comments
This bug also exists in Windows PowerShell (no core) |
'/' is allowed in registry key names. Can you to try escape '/'? |
@iSazonov but I like automatic processing slash in powershell. (like file path) |
To be clear: The real bug is that As @iSazonov points out, (Unfortunately, the objects returned by Using one of your examples: That |
@mklement0 I understand. item name allow use '/' is too bad 😂😂😂 |
That's why I'm more inclined to think that we need to optimize providers and use types instead of strings. |
@iSazonov: What do you mean by using types instead of strings? |
Providers work with strings and do parsing its on every operation. This results in poor performance and problems like this. |
Tracing this, it looks like there has already been some consideration of this in the The comment seems to indicate that unless both back and forwards slashes are used, we want to treat forward slashes as back slashes. That seems a bit strange to me, but looking for input. |
Running |
Related #6833 - seems it is really problem. |
It seems like the fix for this would be to make providers responsible for path handling and manage their own directory char separators. So that way a registry provider can recognise While there's some consideration about ease of use for users, I think that fidelity to the native environment takes priority there. My concern is that this could constitute a spiritual breaking change in PowerShell, whereby it's no longer "PowerShell handles cross-platform paths" but "providers are responsible for their paths and the filesystem provider treats |
@rjmholt From MSDN on the structure of the registry
So the natural path separator is |
Right, with the tricky bit being "as appropriate". The definite bug above is that reading a registry key behaves inconsistently with creating a registry key with respect to path normalisation. But the question remains: do we always do the normalisation and possibly hide some native corner cases (and ideally provide a well-documented way to escape paths), or do we only normalise paths when it doesn't collide with the native implementation? UNIX filenames allow (ASCII) |
Tagging this for committee review so that it can be discussed alongside #6833. |
@PowerShell/powershell-committee reviewed this and similar to #6833, path normalization should happen within the provider. If the registry provider is inappropriately normalizing the path, that is a bug that should be fixed. |
In Registry provider we need
I am not sure that it is all that we should make to fix the bug. |
@SteveL-MSFT Taking in account #10215 (PowerShell crash) please weigh the issue. |
@iSazonov since the recursion issue repros with 5.1, this is not a regression. It's also an unlikely user scenario and I haven't seen many reports of this. I would like to have this fixed, but I don't think it changes the priority. |
It absolutely is inappropriately normalizing the path and causes a few other problems, I realize now I should've posted to this thread a fix, but I believe The registry allows slashes |
got almost a same bug. Create some registry key 'Some_key' and create a subkey named '/' (slash only). Run |
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically. Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original. |
Steps to reproduce
Expected behavior
Actual behavior
Environment data
Summary
after trying, I found the law.
related cmdlets
The text was updated successfully, but these errors were encountered: