Need a setting to force case-sensitive folder support

[adpa]

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
}

[bobbrow]

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)

[adpa]

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.

[bobbrow]

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.

[adpa]

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.

[mtwilliams]

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.

[bobbrow]

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.

[fahimp3]

I've been following this for months now. Still no progress. Do they only do the top of the (thumbs up) list first?

[sean-mcmanus]

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.

[fiveohhh]

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"
  ] 

[drq883]

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.

[stoperro]

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.

[laukikd]

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.

[sean-mcmanus]

@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.

[diablodale]

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.

[tvb377]

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.

[Zingam]

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.

[Zingam]

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.

[sean-mcmanus]

@Zingam Linux/Mac is currently case sensitive already so the renaming of files should work -- what exactly was the failure from the rename? It may be a VS Code issue. Code analysis on Windows will use the casing of the file on disk -- there isn't a known bug in regards to the code analysis casing so if you have repro more details, can you file a bug? This #1994 issue is tracking enabling the database (and other components that operate on the "all caps" file names) to have case sensitive file handling on Windows.

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.13.0 .