vscode-cpptools
vscode-cpptools copied to clipboard
microsoft
Need a setting to force case-sensitive folder support
System
Windows 10, Version 1703 (OS Build 15063.966) VSCode 1.23.1 Cpptools 0.17.0
Description
I'm seeing issues with workspaces on drives mapped using the built-in Windows NFS client (i.e., the one installed from "Windows Features -> Services for NFS -> Client for NFS").
With case sensitivity enabled (mount option casesensitive=yes), the extension logs an error: Unable to retrieve file system information for <path>. error = -1 for paths in browse.path that reside on the NFS drive. Tooltips and navigation shortcuts (e.g., "Go to Definition" and "Switch Header/Source") subsequently fail in this configuration because the extension cannot find my files.
With case sensitivity disabled (casesensitive=no), the error goes away and indexing seems to work, but any files opened using navigation shortcuts have their paths converted to ALL CAPS and you can end up with duplicate tabs (one with normal casing and one with all caps) or duplicate search results if the file in question was already opened through the Explorer pane.
Sample mount output
>mount -o casesensitive=yes <servername>:/share x:
x: is now successfully connected to <servername>:/share
>mount
Local Remote Properties
-------------------------------------------------------------------------------
x: \\<servername>\share UID=<uid>, GID=<gid>
rsize=131072, wsize=131072
mount=soft, timeout=6.4
retry=1, locking=yes
fileaccess=755, lang=ANSI
casesensitive=yes
sec=sys
Sample Cpptools log
IntelliSense Engine = Default.
The extension will use the Tag Parser for IntelliSense when #includes don't resolve.
Autocomplete is enabled.
Error squiggles are enabled.
File exclude: **/.git
File exclude: **/.svn
File exclude: **/.hg
File exclude: **/CVS
File exclude: **/.DS_Store
File exclude: **/.vscode
Search exclude: **/node_modules
Search exclude: **/bower_components
Search exclude: **/.vscode
Code browsing service initialized
Unable to retrieve file system information for X:\vscode-cpp-test. error = -1
Folder: C:/TOOLS/MINGW64/LIB/GCC/X86_64-W64-MINGW32/5.3.0/INCLUDE/ will be indexed
Folder: C:/TOOLS/MINGW64/LIB/GCC/X86_64-W64-MINGW32/5.3.0/INCLUDE-FIXED/ will be indexed
Folder: C:/TOOLS/MINGW64/X86_64-W64-MINGW32/INCLUDE/ will be indexed
Discovering files...
Processing folder (recursive): C:/TOOLS/MINGW64/LIB/GCC/X86_64-W64-MINGW32/5.3.0/INCLUDE/
Processing folder (recursive): C:/TOOLS/MINGW64/LIB/GCC/X86_64-W64-MINGW32/5.3.0/INCLUDE-FIXED/
Processing folder (recursive): C:/TOOLS/MINGW64/X86_64-W64-MINGW32/INCLUDE/
Discovering files: 2283 file(s) processed
0 file(s) removed from database
Done discovering files.
Parsing remaining files...
Parsing: 0 files(s) processed
Done parsing remaining files.
Sample Cpptools configuration
{
"configurations": [
{
"name": "MinGW",
"intelliSenseMode": "clang-x64",
"compilerPath": "C:/tools/mingw64/bin/gcc.exe",
"includePath": [
"${workspaceFolder}",
"${workspaceFolder}/foo",
"${workspaceFolder}/bar/baz"
],
"defines": [],
"browse": {
"path": [
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
},
"cStandard": "c11",
"cppStandard": "c++17"
}
],
"version": 4
}
We currently only turn on case-sensitive file system support on Windows when using the Windows Subsystem for Linux (WSL).
We need to add a proper setting for this, ~~but in the meantime you might be able to trick the extension into thinking you are using WSL (and therefore turn on case-sensitivity support) by adding a bogus folder to the includePath that looks like a linux path string (e.g. /mnt/c/include), and then reloading the window.~~ (EDIT: this workaround no longer applies)
It looks like that trick won't work, unfortunately. I tried adding /mnt/c/include and a couple minor variations to both includePath and browse.path per your suggestion, but the indexing error persisted. I don't have WSL installed, though, in case that's important.
A setting to override the automatic WSL detection does sound promising.
The case sensitivity isn't critical for what I'm doing. Case insensitive is the default for NFS on Windows. I just tried the case sensitivity option hoping that it might solve the ALL CAPS behavior with the navigation shortcuts. I think I would be happy if I could find a solution for either side of the problem.
Sorry, I didn't check your Windows 10 version when I wrote that. ~~If you have build 17110 or higher, the trick should work.~~ (EDIT: this trick does not work anymore) The extension won't support case-sensitive files on earlier versions of Windows 10 because 17110 was when WSL started marking its root folder as case-sensitive.
Ah, thanks for clarifying. Unfortunately, I'm in a corporate environment where I don't have control over the Windows updates to move to a newer build.
Is there any impetus to add a flag to control case sensitivity?
Just got bit by this because the top-level directory for my projects had the FILE_FLAG_POSIX_SEMANTICS flag set and it was inherited.
We prioritize feature requests based on demand (measured by upvotes and duplicate issues). Please add your +1 to this issue to bump up the priority.
I've been following this for months now. Still no progress. Do they only do the top of the (thumbs up) list first?
Is this a request for a setting that would treat all file paths as case-sensitive, as if running on LInux/Mac/WSL or to enable case sensitivity on a per-directory basis (as described in https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/)? We might need to separate these into two issues if another issue doesn't exist.
I would like to override the default and be able to force it one way or another. If possible, by individual folder, but for now, a global setting would work for me.
Something like this would work:
"forceCaseSensitivitySettings": "CaseSensitive"
or
"caseSensitiveSetting: [
"some/path/": "CaseSensitive",
"some/other/path/": "NotCaseSensitive"
]
Please put this on the high-priority list. Until you update it, I'll be using Atom instead. There are many nice features in VSCode, but this is a show-stopper for me.
I don't understand why IntelliSense tries to convert paths to ALL CAPS, it could store actual information internally. Gives me similar problems with Visual Studio C++. Code compiles well with compiler (cl.exe), yet IntelliSense converts to ALL CAPS and fails to find file. In the past it resulted occasionally in duplicated tabs too.
So after 6 Months..... Is there a way to do something like "forceCaseSensitivitySettings": "CaseSensitive"? If not how can we use linux based mounts (NFS) in windows? I just need something for whole workspace or entire work folder Whenever I do go to definition, it opens a 2nd tab in ALL CAPS If this feature is not available, is this issues in a list of priorities? Where is that list? In any case I guess I have to give up on VSCode if I cant configure this. I was rooting for VSCode and suggesting this to my team, but I have to stop since this just slows me down and not something I can live with.
Hope that some one answers these set of questions.
@laukikd We support case sensitivity if "WSL" mode is enabled, i.e. if you install WSL and reference a WSL path, such as "/usr/bin/gcc" in the compilerPath...or via opening your workspace with the remote WSL extension (which will run our Linux binaries on Windows in WSL).
Our "upvote" feature list https://github.com/Microsoft/vscode-cpptools/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc , so this is around 16th on that list, but this issue isn't on any of our recent planning milestones yet.
Blindly uppercasing all alphabetic ASCII characters corrupts the paths of/when using cross-platform projects and libraries. The paths/files of these libraries and git repos are correct and fully expressed with cases. For example, this C++ extension fails to work correctly with the CMake extension. The CMake extension leads to generation of compile_commands.json for example:
[
{
"directory": "C:/njs/dp.kinect3/build",
"command": "C:\\PROGRA~2\\MICROS~1\\2019\\COMMUN~1\\VC\\Tools\\MSVC\\1425~1.286\\bin\\Hostx64\\x64\\cl.exe /TP -DEXT_WIN_VERSION -DINTERNAL_JIT_ANIM -DMAXAPI_USE_MSCRT -DWIN64 -DWIN_VERSION -D_DEBUG -D_NO_ASYNCRTIMP -D_NO_PPLXIMP -D_USRDLL -D_WINDLL -Ddp_kinect3_EXPORTS -I. -IC:\\njs\\max-sdk\\source\\c74support\\max-includes -IC:\\njs\\max-sdk\\source\\c74support\\jit-includes -IC:\\njs\\max-sdk\\source\\c74support\\msp-includes -IC:\\njs\\maxcpp\\maxcpp -I\"C:\\Program Files\\Azure Kinect SDK v1.4.0\\sdk\\include\" /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od /RTC1 -MDd /GL /W4 /wd4200 /WX /ZH:SHA_256 /arch:AVX -std:c++17 /FoCMakeFiles\\dp.kinect3.dir\\dp.kinect3.cpp.obj /FdTARGET_COMPILE_PDB /FS -c C:\\njs\\dp.kinect3\\dp.kinect3.cpp",
"file": "C:/njs/dp.kinect3/dp.kinect3.cpp"
}
]
The path -IC:\\njs\\maxcpp\\maxcpp is correctly expressed. And the project correctly compiles and links. The failures are isolated to this C++ extension and its intellisense functionality.
C:\njs>fsutil.exe file queryCaseSensitiveInfo maxcpp
Case sensitive attribute on directory C:\njs\maxcpp is enabled.
Unfortunately, this C++ extension corrupts the path and its debug log output surfaces this as:
Includes:
C:\NJS\DP.KINECT3\BUILD
C:\NJS\MAX-SDK\SOURCE\C74SUPPORT\MAX-INCLUDES
C:\NJS\MAX-SDK\SOURCE\C74SUPPORT\JIT-INCLUDES
C:\NJS\MAX-SDK\SOURCE\C74SUPPORT\MSP-INCLUDES
C:\NJS\MAXCPP\MAXCPP
C:\PROGRAM FILES\AZURE KINECT SDK V1.4.0\SDK\INCLUDE
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.25.28610\INCLUDE
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.25.28610\ATLMFC\INCLUDE
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\UM
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\UCRT
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\SHARED
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\WINRT
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\CPPWINRT
The 5th include path has been corrupted and is incorrect. Various NTFS directories on this computer's SSD are case sensitive and need to be case sensitive as the dependent projects are cross-platform where case-sensitivity is needed. Projects are compiled and linked in multiple simultaneous platforms and file systems. It is not this or that. It is both at the same time. Last century when Windows didn't live in cross-platform scenarios it was possible to blindly alter case. This is no longer possible and leads to havok as this issue documents.
File system case-sensitivity is orthogonal to "running on windows, WSL, etc. The following is errant logic:
We support case sensitivity if "WSL" mode is enabled, i.e. if you install WSL and reference a WSL path, such as "/usr/bin/gcc" in the compilerPath...or via opening your workspace with the remote WSL extension (which will run our Linux binaries on Windows in WSL).
Paths, configuration values, etc. should not be corrupted by changing their byte (aka ASCII) values. It is probably impossible for an app like this C++ extension to construct some logic to derive if it should alter the individual byte characters in a configuration or path. This was further cemented in 2018 when NTFS and WSL again updated shared filesystem features and ended the old ways of Win32-only-case-doesn't-matter.
Workarounds like fsutil.exe file SetCaseSensitiveInfo maxcpp disable are the equivalent of playing a game of Wack-a-mole 🔨 due to non-inheritance of that attribute + the side-affect of all effected folders afterwards having different behaviors in other environments like WSL, git itself, etc.
I can't easily imagine the value of blindly uppercasing paths. Why? Because if you are assuming case doesn't matter...then upper-casing doesn't matter because the case doesn't matter. Perhaps you want to uppercase them for some internal intelllisense database de-duping. Fine. Then restrict the uppercasing to your internal database and not to the broader usage of paths/configuration values. And if this extension really really won't change this "I'm Win32 so I must uppercase", then do the additional API call to query the directory to see if it is case-sensitive and for those directories do not uppercase corrupt the path.
Ran into this as well when combining with Cmake Tools on a mac. I work with Android source which recommends working inside a case-sensitive filesystem, which is what I do. CMake Tools properly gives the expected paths, ie. /usr/include/QtCore but cpptools lowercases the whole thing to /usr/include/qtcore and then fails to find the path :(
I've upvoted the issue.
@tw-thalmic If you are seeing lower-casing, then I believe it's caused by CMake Tools (which I know has code that sometimes does lowercasing of the paths we receive from it), because our C/C++ extension only does upper casing for normalization (and normally only on Windows and not Linux or Mac). If you set C_Cpp.loggingLevel to "Debug" you can see more details about where the incorrectly cased paths are coming from in the C/C++ logging (look for the configuration provider info).
@sean-mcmanus thanks for the info! I had thought it was cpptools since I saw the proper-cased path in the C/C++ debug logs, which then later became lowercased. I didn't save that set of logs so I can't paste them here, but I'll take another look based on this explanation :)
This upper-casing behavior is beyond frustrating. The number of hours I lost tracking this down, and knowing that the code to fix this exists but it's hidden behind some "magic" path detection code and not a setting... 😠.
EDIT: Aaand it sounds like the "workaround" no longer works. Cool.
Anyway, until this gets fixed, here's some advice for my fellow Linux travelers to deal with it.
What's the problem?
On the Windows version of VSCode, search paths get converted to upper case. That means even if you specify your IntelliSense (configurations.includePath) and file (configurations.build.path) search paths in c_cpp_properties.json with correct case, case information gets discarded. So instead of searching C:\Work\my-game\src, it searches C:\WORK\MY-GAME\SRC. You can watch this happen by enabling logging and making changes to c_cpp_properties.json.
Case sensitivity has been supported on Windows for a long time, but until WSL, it might be fair to say it didn't get used much.
Case sensitivity can be enabled on a per-folder basis. From a command prompt or powershell you can use the following command to check if the folder you're in is sensitive or not.
fsutil.exe file queryCaseSensitiveInfo .
Until this is fixed we can't stop VSCode from mangling its search paths. That said, we do know what it's doing wrong, so we can work around it a few different ways. Heads up though, they're all terrible.
Solution 1: Re-enable case insensitivity
In practice you shouldn't have 2 nearly identical filenames, so until this is resolved you can switch sensitivity off.
Open a PowerShell as Administrator, browse to the folder you want to correct, and run these commands to fix the current folder and every subfolder.
fsutil.exe file setCaseSensitiveInfo . disable
(Get-ChildItem -Recurse -Directory).FullName | ForEach-Object {fsutil.exe file setCaseSensitiveInfo $_ disable}
(Snippet is borrowed from StackOverflow, so there might be a way to do this in 1 line, but it's not important).
TIP: You might run in to this case sensitivity problem when working with the Unity game engine. Same fix here will help you deal with it. Be warned: You can trick Unity in to thinking you've fixed the case issues by changing only the home folder's sensitivity settings. Unity will mostly work, but you will end up with multiple copies of certain files.
Solution 2: Create upper-case symlinks
NOTE: If you're not an administrator on your PC, you might need to enable developer mode first.
Because the naughty code in VSCode is making things upper case, we could alternatively create some throw-away symlinks. Yes this is undesirable clutter, but it is a workaround if you're like me and have embraced case sensitivity even on Windows.
I work out of a folder C:\Work\. Because nearly everything I do is Linux friendly, my work folder is case-sensitive, meaning all child folders are also case sensitive. A typical path for me might look like this: C:\Work\MyGame\src. The C:\ drive is insensitive, the Work folder is sensitive, and after the workaround above MyGame will be insensitive. The naughty code will mangle my path to C:\WORK\MYGAME\SRC. Everything but the MYGAME part will work.
From a command prompt (not PowerShell`) you can make a symlink.
cd C:\Work
mklink /D MYGAME MyGame
You'll get something like this when you type dir.
Directory of C:\Work
2020-07-20 01:02 AM <DIR> .
2020-07-20 01:02 AM <DIR> ..
2020-07-20 01:02 AM <SYMLINKD> MYGAME [MyGame]
2020-07-19 11:33 PM <DIR> MyGame
And the path mangling will find a valid path.
Wrap-up
Both of these solutions are terrible, but the alternative is to fix it yourself. 🤷
This is also completely broken on MacOS if filesystem is set as case-sensitive. CMake/Intellisense creates all these lowercase paths which are invalid. For example, my source code is in my home somewhere which is /Users/myusername/... and the browsePath and includePath contain /users/myusername/.... Or when it looks for Qt in brew managed /usr/local/opt/...QtWidgets.framework is transformed to qtwidgets.framework, which obviously doesn't exist.
Quite sad. Does it work properly on linux??
@jeff-dagenais The lowercasing is coming from CMake tools and is only an issue on Mac and not Linux or (case insensitive) Windows. There's an issue tracking that in the CMake tools repo.
VSCode can't even handle renaming files with different casing properly.. wut..?
Is the cause for this the same as for https://stackoverflow.com/questions/65326006/how-do-i-get-visual-studio-code-in-windows-against-wsl-to-be-case-sensitive?
No. It's a problem though because WSL (and Windows in general) can be case sensitive, and because VS Code runs on more than just Windows.
On Mon, Dec 21, 2020, 09:11 mikebaz [email protected] wrote:
Is the cause for this the same as for https://stackoverflow.com/questions/65326006/how-do-i-get-visual-studio-code-in-windows-against-wsl-to-be-case-sensitive ?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode-cpptools/issues/1994#issuecomment-748993181, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL7MCJCNEIDQE2VKXHXTJ3SV5JRVANCNFSM4E7Z33UQ .
@mikebaz Yes. We recommend users remote to WSL instead of accessing WSL files from Windows. @mikekasprzak Case sensitivity works fine in WSL via remote, Linux, and OSX -- it's just a problem on Windows with case sensitive folders enabled.
After having spent over one day digging through countless howtos, emails and whatnot while trying to understand why intellisense fails to find some of my includes it's a bit frustrating to see that the root cause is so old and seems to be neglected.
I'm only a user of cpptools. As far as I understood the numerous comments, converting paths to uppercase is done as a step in canonicalization to make life easier when doing path comparisons. In case I'm right I think that the comment above by @diablodale and the comment by @bobbrow in issue #3394 are sufficient.
At least for local file systems (both on Mac and Windows) it should be fairly easy to have the comparison/canonicalization detect case sensitivity automatically. For networked file systems it either proves impossible to get path comparison (or canonicalization) right, then please add a manual setting that gives the algorithm the path specific info it needs, or it can be done, then please implement it.
This is probably (un)related: I have experienced the following issue - when renaming a folder on macOS (or maybe Linux) and the committing it it wasn't properly renamed (changing the letter capitalization):
FolderWithCapitalLetters -> folderwithsmallleters
I figured out the workaround is to rename the folder to something else like -> FolderWithCapitalLetters -> somethingElse -> folderwithsmallleters
I don't know if this is Unix/mac specific (or git). In the Explorer window the Folder appeared correctly but in my GitHub repository it wasn't renamed and thus there were issue.
C:/TOOLS/MINGW64/LIB/GCC/X86_64-W64-MINGW32/5.3.0/INCLUDE/
I had some similar issue with MSVC and code analysis a while ago. The compiler apparently converts all paths to small letters if I recall correctly and I use CamelCase names a lot in my paths and this caused issues. Or maybe I'm wrong and the paths were capitalized in any case the issue was that the paths names were changed by the compiler/analyzer. I don't know what. I tried to complain without success.