Repository navigation
WSL has case-sensitive file system in pre-release builds #1694
Description
Activity
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.
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 = -1Our code is failing to find the path. Do they still exist?
They do. (I checked both the linux packages and the filesystem directory)
Bob Brown (@bobbrow) Any ideas? Could this be an Windows Insiders bug?
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.
I'm not seeing any problem with 17074 either.
☹️ I have an update pending for 17120.1, so I can see if that changes anything.
No dice. Still seeing the same thing in 17120.
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) .
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.
I experience this same problem on both Mac and with MSYS2/Mingw on Windows.
Files that are "behind" symlinks are not found by Intellisense.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.
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.
10 remaining items
Same issue here after updating to April Creators Update.
I'm almost done with the fix for this. We're hoping to put out an insiders release with the fix this week. 🤞
Reacted by WSLUser, n3rd4i, 胡玮文, ljxfstorm, Gal Aharoni and Adrian Georg HerrmannReacted by Henrique Dias and Jordi BunsterWe 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.
Reacted by Lillian Grassin-Drake and BlealtanJust 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!
SIDE NOTE: I just discovered the extension now auto-detects WSL/include paths without c_cpp_properties.json and it's working beautifully!
Reacted by Henrique DiasHere's working too Bob Brown (@bobbrow)!
Great, thanks a lot!
Glad to hear this is working for everyone! I'm going to close the issue now.
- locked and limited conversation to collaborators
on Oct 15, 2020
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.hetc). I've checked that the includepath for gcc/WSL hasn't changed, and I haven't touched myc_cpp_properties.json(which I'll include below). I also just updated Windows earlier this week and VSCode yesterday.