Skip to content

WSL has case-sensitive file system in pre-release builds #1694

Closed
Closed
WSL has case-sensitive file system in pre-release builds#1694
Labels
Language ServicebugfixedCheck the Milestone for the release in which the fix is or will be available.
Milestone
April 2018

Description

@lilgrassin
Lillian Grassin-Drake (lilgrassin)
opened on Mar 16, 2018

My system:
Windows 10.0.17115 (insider build)
VSCode 1.21.1
Cpptools 0.15.0

I've been using Intellisense under the WSL with no issue for a while now, but today when I opened up a C project (which was working the other day), Intellisense was able to find files in the project folder, but not those under WSL (e.g. stdio.h, stdlib.h etc). I've checked that the includepath for gcc/WSL hasn't changed, and I haven't touched my c_cpp_properties.json (which I'll include below). I also just updated Windows earlier this week and VSCode yesterday.

image
image

{
    "configurations": [
        {
			"name": "Win32",
			"intelliSenseMode": "clang-x64",
			"includePath": [
				"${workspaceRoot}",
				"${workspaceRoot}/gtest/include",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/c++/7",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/x86_64-linux-gnu/c++/7",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/c++/7/backward",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/lib/gcc/x86_64-linux-gnu/7/include",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/local/include",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/x86_64-linux-gnu",
				"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include"
			],
			"defines": [
				"__linux__",
				"__x86_64__"
			],
			"browse": {
				"path": [
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/c++/7",
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/x86_64-linux-gnu/c++/7",
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/lib/gcc/x86_64-linux-gnu/7/include",
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/local/include",
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed",
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/x86_64-linux-gnu",
					"${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/*"
				],
				"limitSymbolsToIncludedHeaders": true,
				"databaseFilename": ""
			}
		}
    ],
    "version": 3
}

Activity

  1. sean-mcmanus commented on Mar 16, 2018

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Mar 16, 2018
    Contributor

    Another user has also reported some issue with WSL failing to find the system headers. I haven't been able to repro a problem yet, but we could fail to find includePaths if the paths include symbolic links, because the links in the path don't exist on Windows. We're actively working on improving the WSL scenario via allowing users to just set the compilerPath and allowing symbolic links in the include path, which may fix this issue.

    We haven't updated 0.15.0 in a while, so it seems like there was a change with the Windows insider build.

  2. lilgrassin commented on Mar 16, 2018

    @lilgrassin
    Lillian Grassin-Drake (lilgrassin)
    on Mar 16, 2018
    Author

    If it helps, I just checked the logs and the specific error is:

    Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/c++/7. error = -1
Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/x86_64-linux-gnu/c++/7. error = -1
Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/lib/gcc/x86_64-linux-gnu/7/include. error = -1
Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/local/include. error = -1
Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed. error = -1
Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/x86_64-linux-gnu. error = -1
Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/*. error = -1

  3. sean-mcmanus commented on Mar 16, 2018

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Mar 16, 2018
    Contributor

    Our code is failing to find the path. Do they still exist?

  4. lilgrassin commented on Mar 16, 2018

    @lilgrassin
    Lillian Grassin-Drake (lilgrassin)
    on Mar 16, 2018
    Author

    They do. (I checked both the linux packages and the filesystem directory)

  5. sean-mcmanus commented on Mar 16, 2018

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Mar 16, 2018
    Contributor

    Bob Brown (@bobbrow) Any ideas? Could this be an Windows Insiders bug?

  6. bobbrow commented on Mar 16, 2018

    @bobbrow
    Bob Brown (bobbrow)
    on Mar 16, 2018
    Contributor

    I have a laptop that was flighted to 17074 that I can try. On 16299, I can verify that IntelliSense isn't working when there are symlinks in the includePath. (e.g. /usr/include/c++/5.4.0 which links to /usr/include/c++/5). Using 5 instead of 5.4.0 resolves it for me.

    image

  7. bobbrow commented on Mar 16, 2018

    @bobbrow
    Bob Brown (bobbrow)
    on Mar 16, 2018
    Contributor

    I'm not seeing any problem with 17074 either. ☹️

  8. lilgrassin commented on Mar 16, 2018

    @lilgrassin
    Lillian Grassin-Drake (lilgrassin)
    on Mar 16, 2018
    Author

    I have an update pending for 17120.1, so I can see if that changes anything.

  9. lilgrassin commented on Mar 17, 2018

    @lilgrassin
    Lillian Grassin-Drake (lilgrassin)
    on Mar 17, 2018
    Author

    No dice. Still seeing the same thing in 17120.

  10. cylonid commented on Mar 17, 2018

    @cylonid
    Hannes U. (cylonid)
    on Mar 17, 2018

    Unable to retrieve file system information for C:\Users\lillian\AppData\Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/usr/include/c++/7. error = -1

    Your log shows inconsistent usage of directory separators (slash vs backslash) Lillian Grassin-Drake (@lilgrassin) .

  11. bobbrow commented on Mar 19, 2018

    @bobbrow
    Bob Brown (bobbrow)
    on Mar 19, 2018
    Contributor

    Uwe Heinkel (@uwe-h) Windows doesn't actually care about the direction of the slashes, but we should probably unify them after the environment variable is evaluated.

  12. WSLUser commented on Mar 20, 2018

    @WSLUser
    WSLUser
    on Mar 20, 2018

    Slash vs backslash won't matter in 17120. See this blog. Just make sure it's all consistent (no mix and match in a path.)

    As for environmental variables, WSLENV is your friend. See this.

  13. gregersn commented on Mar 21, 2018

    @gregersn
    Greger (gregersn)
    on Mar 21, 2018

    I experience this same problem on both Mac and with MSYS2/Mingw on Windows.
    Files that are "behind" symlinks are not found by Intellisense.

  14. sean-mcmanus commented on Mar 21, 2018

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Mar 21, 2018
    Contributor

    Greger (@gregersn) Your issue sounds completely different. Can you file a new bug and provide more repro details? Paths with symlinks work for me with includePath and browse.path and we haven't received any other reports of this. The only known issue with symlinks is with WSL, because the WSL symlinks are not natively traversable in Windows without calling into WSL (which is planned to be fixed in April). The files may not be found due to other issues, which may be fixed in our upcoming 0.16.0.

  15. Blealtan commented on Apr 11, 2018

    @Blealtan
    Blealtan (Blealtan)
    on Apr 11, 2018

    Here I repro this issue on multiple devices and multiple builds. Since build 17103 I think, I started to suffer from this issue on both my Windows Insider devices (slow ring for my PC, fast ring for my laptop), while VSCode and cpptools version both keeps latest, and remains this situation till now. RS4 has recently graduated to Release Preview status, and if anyone try the current Inside Release Preview (which I think is pretty safe even for development environment), the issue should be reproduced.

    Also, here in my case (#1802), there is nothing to do with symlinks; every level in the path is able to be seen as a folder in Explorer.

  16. 10 remaining items

  17. Bob Brown (bobbrow)
    modified the milestones: , April 2018 on Apr 11, 2018

  18. hacdias commented on May 1, 2018

    @hacdias
    Henrique Dias (hacdias)
    on May 1, 2018

    Same issue here after updating to April Creators Update.

  19. bobbrow commented on May 1, 2018

    @bobbrow
    Bob Brown (bobbrow)
    on May 1, 2018
    Contributor

    I'm almost done with the fix for this. We're hoping to put out an insiders release with the fix this week. 🤞

  20. Bob Brown (bobbrow)
    added
    fixedCheck the Milestone for the release in which the fix is or will be available.
    on May 2, 2018

  21. bobbrow commented on May 4, 2018

    @bobbrow
    Bob Brown (bobbrow)
    on May 4, 2018
    Contributor

    We just published https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.0-insiders2 with a fix for this. Please go give it a try and let us know if you have any issues with it.

    NOTE: There is still an issue switching between WSL and non-WSL configs, so you may need to reload the VS Code window if you switch to/from a WSL-enabled config to a config not using WSL.

  22. lilgrassin commented on May 4, 2018

    @lilgrassin
    Lillian Grassin-Drake (lilgrassin)
    on May 4, 2018
    Author

    Just tried the update and it seems to be fixed. No more errors and I'm able to peek/goto definitions/declarations and get suggestions. Linting is also working. Thanks for the prompt fix!

  23. lilgrassin commented on May 4, 2018

    @lilgrassin
    Lillian Grassin-Drake (lilgrassin)
    on May 4, 2018
    Author

    SIDE NOTE: I just discovered the extension now auto-detects WSL/include paths without c_cpp_properties.json and it's working beautifully!

  24. hacdias commented on May 4, 2018

    @hacdias
    Henrique Dias (hacdias)
    on May 4, 2018

    Here's working too Bob Brown (@bobbrow)!

  25. flxflx commented on May 4, 2018

    @flxflx
    Felix Schuster (flxflx)
    on May 4, 2018

    Great, thanks a lot!

  27. bobbrow commented on May 8, 2018

    @bobbrow
    Bob Brown (bobbrow)
    on May 8, 2018
    Contributor

    Glad to hear this is working for everyone! I'm going to close the issue now.

  28. Bob Brown (bobbrow)
    closed this as completedon May 8, 2018
  29. github-actions
    locked and limited conversation to collaborators on Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Language ServicebugfixedCheck the Milestone for the release in which the fix is or will be available.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions