Match PATH case insensitively in Windows installer
#5680
Conversation
The Windows installer expands the path to the `C:\Program Files` directory using the standard casing for this. However, our `PATH` value does not need to contain the same case, since on Windows this directory is case insensitive, and as a result, if the two differ in case, we don't correctly detect that the Git executable is in `PATH`. Let's fix this by lowercasing both versions of the text. Note that instead of using the `Lowercase` function, which deals only with ASCII characters, we use `AnsiLowercase`, which, despite its name, uses the current Windows locale. This is not guaranteed to produce correct results in all cases because the file system's case folding is done in the kernel in a locale-insensitive way based on the tables created when the file system was created, but there's no way to do better than this in the general case since we don't have functionality to implement the kernel's case mapping and it is impossible to correctly fold arbitrary Unicode text in a locale-insensitive way. We therefore adopt the least bad option available while continuing to support Windows.
|
My apologies for being a bit slow to take a look at this; life has intervened. I hope to give it a whirl on a Windows VM shortly. |
chrisd8088
left a comment
chrisd8088
left a comment
There was a problem hiding this comment.
This looks good; thanks for your patience. From my own testing, I agree this fixes the reported problem.
I also found that attempting to make C:\ case-sensitive with fsutil.exe file setCaseSensitiveInfo 'C:\' enable or similar commands, even in the Administrator role, was prevented by Windows. So, I believe that rules out the possibility there could be both a C:\Program Files and a C:\program files (which, if it were possible, would argue for case-sensitive matching against C:\Program Files since that's the OS-defined location we get from the {commonpf*} variables).
I also note that the comparison we perform here is strictly against that value (the one from the appropriate {commonpf*} variable), so although we may find a git executable somewhere else, including in a case-sensitive folder location, the case-sensitivity of that location doesn't matter for the sake of our check since the comparison value we use is always the (now lower-cased) C:\program files string.
2 participants
The Windows installer expands the path to the
C:\Program Filesdirectory using the standard casing for this. However, ourPATHvalue does not need to contain the same case, since on Windows this directory is case insensitive, and as a result, if the two differ in case, we don't correctly detect that the Git executable is inPATH.Let's fix this by lowercasing both versions of the text. Note that instead of using the
Lowercasefunction, which deals only with ASCII characters, we useAnsiLowercase, which, despite its name, uses the current Windows locale.This is not guaranteed to produce correct results in all cases because the file system's case folding is done in the kernel in a locale-insensitive way based on the tables created when the file system was created, but there's no way to do better than this in the general case since we don't have functionality to implement the kernel's case mapping and it is impossible to correctly fold arbitrary Unicode text in a locale-insensitive way. We therefore adopt the least bad option available while continuing to support Windows.
Fixes #5679