-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
On Windows and macOS, Get-Item and Get-ChildItem report file names as specified, not their actual case #13190
Comments
@mklement0 does directly calling a .NET API to retrieve the name report it with the correct casing? |
Good point, @vexx32 - indeed, the underlying .NET Core API - as well as .NET Framework - does the same: PS> [System.IO.FileInfo]::new("$pshome/POWERSHELL.config.json").Name
POWERSHELL.config.json # !! name as specified, not the actual casing However, it does so for directories too - whereas PowerShell (Core only!) exhibits the desired behavior: # .NET
PSonWin> [System.IO.DirectoryInfo]::new('c:\wINdows').Name
wINdows # !! name as specified, not the actual casing
# PowerShell Core only (WinPS exhibits the behavior above).
PSonWin> (Get-Item C:\wINdows).Name
Windows # OK, true casing So the question is:
|
I'd imagine since we're interested in supporting Unix that we'd want casing to be accurate, aye. I'm surprised .NET Core hasn't got that ironed out yet, it'll make things very complicated for Unix developers wanting to use those APIs 😬 |
Well, it's not strictly a functional problem, because it only applies to platforms with case-insensitive file systems, notably macOS and Windows - on Linux, with its case-sensitive file system you have to supply the case-accurate representation to begin with, otherwise you won't find the file / directory. Still, I imagine that users consistently expect to get the true casing of file-system items when they call I'm surprised that no one (to my knowledge, based on searching through the issues) has complained in the .NET Core repo about this. |
I'd speculate that it is because performance reasons - re-combine all path is very expensive. See #9250 as sample. |
So there's no single system call on all platforms with case-insensitive file-systems that would give you the case-exact form of a path (e.g., returning Given that we currently do it - but for directories only - how do we do it? |
Yes, only way to get an original value is to read from system.
See #9250. GetCorrectCasedPath() explicitly does this for directories. |
Thanks for the link, @iSazonov. I think it's more important for us to make Performance is more likely to be a concern when enumerating file-system items, but here we're talking about targeting a given file (pattern), and wanting to know its true name. Note that there are more inconsistencies: # Get-ChildItem with -Filter: Exact case of the *full path*
PS> gci c:\windows\system32 -filter aphost*.dll | % FullName
C:\Windows\System32\APHostClient.dll
C:\Windows\System32\APHostRes.dll
C:\Windows\System32\APHostService.dll
# Get-ChildItem with -Path: Exact case of the *file name only*
PS> gci c:\windows\system32\aphost*.dll | % FullName
C:\windows\system32\APHostClient.dll
C:\windows\system32\APHostRes.dll
C:\windows\system32\APHostService.dll Again: If I use |
Personally I do not like strongly #9250 and GetCorrectCasedPath(). I think if a system is case-insensitive we should follow this - accept a path as user typed and expose an enumerated path in case as it saved in the system. It is less expensive and more predictable. cmd.exe does so:
but PowerShell does extra work: dir c:\windows
Directory: C:\Windows |
We already do honor this for referring to paths and would continue to do so, but since these file systems are also case-preserving, we should honor that too, by reporting the actual name/path when explicitly requesting information about an item. Yes, The extra work that PowerShell already does for directories is helpful - let's do the work for files too. Again: The incidental form of a path I use to refer to an item of interest (case variations, relative vs. absolute path) should not change how its innate properties are being reported. |
Helpful? Get-Item temp:\
Directory: C:\Users\1\AppData\Local
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 20.07.2020 22:45 Temp |
This comment has been minimized.
This comment has been minimized.
Joking aside, @iSazonov, my hope was that what I said above,
makes it generally clear why the behavior is helpful, but let me address your specific example:
Being able to use a case variation is a convenience that has two advantages:
So, no, you most likely wouldn't use the cumbersome-to-type form
Conceptually, there is no change here: just a truthful reporting of the name as it is actually stored in the filesystem. Also note that the pre-#9250 behavior actually caused bugs (e.g. vuejs/vue-cli#648 (comment)), albeit in the context of Even Also, I don't understand your |
@mklement0 My point is that on Windows we never pay attention to path case. It is so many years in cmd.exe and PowerShell too. I never understand when someone (it is not about you) tries to make Windows from Unix and vice versa - each system is good at its own area and if we follow the nature of a system, then we can get more benefits than from limited and expensive imitation. |
I don't think he's asking for resolution to be case sensitive, just for the object to report it's real name. Aside from just being kind of annoying, it's also problematic when creating files based on another file (e.g. I don't have an opinion on if it's ultimately a good idea, but it's not just @mklement0 . It's very aesthetically annoying. |
Indeed, @SeeminglyScience, thanks for clarifying. @iSazonov, to be clear, this has absolutely nothing to do with Unix, and everything to do with case-insensitive file-systems, which happen to be the default kind of file-system on Windows and macOS. If by Unix you mean case-sensitive file-systems, such as on Linux: there, the problem at hand by definition never arises, because the only way to refer to a file or directory is by its case-exact name / path. |
I only mentioned Unix to say that it is pointless to drag something to Windows that works great on Unix because in most cases it will not work well. Each system is good in its area. Again, it is my strong belief that the input paths (as any input data) should remain unchanged. This is exactly what the user expects in common. We shouldn't expand If you say about:
I ask why do you allow unaesthetic typing for yourself? On the console, you will see everything that you typed in an unaesthetic form. Want aesthetics - print it "right"! If an user types PowerShell is already extremely slow due to the fact that it does a lot of extra work that is often unnecessary (globbing, slash normalization and more). |
Easier sometimes.
If you were going to argue that most people don't care, I don't really have a response for that and might be true. But what possible reason would someone have to want it see it that way? Also
This would only apply no non-wildcard paths for a single item. An extra half millisecond isn't likely to make a big difference. |
I assume we could have an option for the file provider to enable this feature, but it should be disabled by default. But really if we say about aesthetics this must be moved to Formatting System. It would be amazing to sacrifice a performance for aesthetics, which is pointless for a script. Main PowerShell principle is do not limit users in their capabilities. Here we impose the transformation on the users.
We do not know how users could use Get-Item. Really the normalization code is on hot path (it normalize every part of the path - for |
Eh, it's less of a problem for me when it's being displayed and more when the Honestly all I personally want is some command to get the correct path. afaik the only way to do it is dipping into p/invoke which never feels worth it interactively (or even as a profile function). I'll let @mklement0 debate the rest, I just wanted to mention it's not just him annoyed by this. |
Actually I think a It'd be nice to have it "fixed" but 🤷 the above is fine imo. @mklement0 feel free to continue on if you disagree, I'm gonna dip from this thread. |
Sorry I tired you :-)
|
You didn't, I never felt strongly about it in the first place.
Call it what you like I guess 🤷 I'll keep calling it correct.
Yeah same problem, really heavy to do it all the way through. It'd be nice as a code prop. |
I will pull the PR. I hope you vote and the PR will be approved. :-) |
Hmm that's a good question... I do like |
Since we read from disk we have to resolve to absolute path like |
Perfect 🙂 |
I appreciate the willingness to tackle this, but I don't think we need a separate property: Unless I'm missing something, the performance impact of doing the right thing automatically should be negligible, because the overhead of determining the case-exact path only ever needs to be incurred when creating a
(As stated, we already do this for Notably, determining the case-exact name is not necessary as part of the path normalizations we seemingly always perform. |
I'm kind of lost at this point as to what you think is actually needed here, @mklement0. |
It's spelled out in detail in the 2nd paragraph and the two associated bullet points, @vexx32. To summarize: action is only ever needed if (a) Please tell me which aspect lacks clarity. |
That makes sense! Sorry, got a bit lost amongst all your emphasis, I couldn't tell what was actually the main point there. Appreciate the clarification! 🙂 |
😁 Granted, sometimes I can slip into putting too much emphasis on the emphasis (if you will), but the rationale behind doing so in my penultimate comment was to highlight that I don't think there's a performance concern here, and that it therefore shouldn't drive the implementation - a direct solution that automatically does the right thing is much more convenient than having to be aware of the problem to begin with and then knowing what alternate property to consult (and having the burden of needing to do so). |
It is a bug in node.js/vue-cli. The issue was closed without investigations by the app owners.
After #9250 FileSystem provider does the normalization for every path again and again. It is extra operation for scripts. Why do my script should works now slower if anybody want "nice output"?
This makes no sense for scripts. If we do it like #9250, then our file operations will be extremely slow. And this is only for the sake of a "beautiful" output in rare cases? |
As @mklement0 said, this current issue would be a small change. No additional action would be needed for the vast majority of cases. It would only be where we're finding files based on direct user input that is affecting case of returned results. |
Let me put it as simply as possible: PowerShell is lying to you if you ask for an object describing the Windows directory and that object reports the directory's name as The directory's true name is Yes, other shells and even .NET are lying to you too, but that's no excuse for us not to do better, especially given that we've half done so already (even if the motivation may have been different originally). Again:
|
So you agree that #9250 should be reverted and a fix you ask should be in another place and normalize a path "only if you ask for an object describing the item"? |
@iSazonov, I hadn't looked closely at #9250 before, but I agree that it's unnecessary to call To summarize, this means that case correction is only required in the following scenarios:
|
Proposed API in .Net Runtime dotnet/runtime#14321 For Windows we could use more fast a workaround
/cc @SteveL-MSFT for tracking .Net issue
|
@iSazonov, thanks for the link. As for the workaround: |
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
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. |
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. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
Note: The problem:
affects only files, not also directories
for file paths, affects all path components.
Simple demonstration (macOS and Windows):
Note how
POWERSHELL.config.json
was reported via.Name
- exactly as specified - even though the actual casing of the filename ispowershell.config.json
Steps to reproduce
Windows and macOS only (platforms with case-insensitive (but case-preserving) file-systems).
Expected behavior
The tests should succeed.
Actual behavior
All tests fail.
Environment data
The text was updated successfully, but these errors were encountered: