You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
IntelliSense with different file system types (Windows 10) #1046
IntelliSense doesn't seem to be working with SSHFS filesystem type in Windows 10 (no import errors detected and no squiggly lines). I know this is a fringe case, but I'm wondering if there is an easy fix.
IntelliSense works fine for this example in the local filesystem as well as on an exfat formatted flash drive.
Steps to Reproduce:
Install winsshfs and mount a remote file system
Open the a project locally from that mounted file system
Reproduces without extensions: No (Need the C++ extension for intellisense)
Sean McManus (@sean-mcmanus) Just tried a 50GB mount and still had the same issue. Strangely, it looks like IntelliSense is still loading because I get the Configure includePath for better IntelliSense results. message (this happens for both mount sizes), but it doesn't detect the import errors.
There are also no problems reported in the console.
Okay, I just set up an sshfs connection using the 4every1 edition 1.5.12.8 and Dokany 0.7.4. I set up a folder on the mount, added an include, and it didn't show an error, just like yours. When I hover over the include, I get the message "FE 'Compiler exited with error - No IL available'". Do you get the same message Jordan Garside (@jordangarside)?
Okay. The compiler failing is almost certainly the cause of the missing squiggles. I'll throw a debugger on there and see if this is a simple fix. Thanks for reporting this issue Jordan Garside (@jordangarside)
Not sure if it's 100% related, but trying to get some feedback regarding the issues I've mentioned here microsoft/vscode#13665. I'm using VSCode, latest build (insiders has the same issue as well) on MacOS with a 1.2G SSHFS mounted directory. Intellisense and autocomplete are completely non-existent. FWIW, I'm mostly editing JS. It's quite frustrating given how much I love the editor (and that Atom won't even handle opening the directory), but having no autocomplete is...painful. Happy to provide any more info that's relevant. This should likely be an issue for anyone else who has to work on a monorepo hosted in a dev VM using SSHFS such that the files don't stay on the local machine.
I get this issue when trying to add a WSL-created directory as an include path. Create any directory from WSL and try to use it as an include path, giving the error:
Unable to retrieve file system information for xxx. error = -1
The directory works fine, is not corrupted, files can be accessed as normal from the file explorer as well as VSCode, but completely breaks the Intellisense apparently. Makes it impossible to use for anything related to WSL
Sean McManus (@sean-mcmanus) No not using WSL2, and I tried both with the Remote extension and also just creating a fresh project and adding a WSL folder to the browse.path or includePath depending on the engine.
I was able to resolve this issue another way, I create a folder for my repos by symlinking a C:/ drive folder, i.e. ~/repos -> /mnt/c/repos.
Like this, I am able to use intellisense on the Windows-side. Otherwise, if the directory is located in the rootfs/ of the WSL installation, it won't work, regardless of permissions. Intellisense can't read any directory in rootfs/
Not an answer, but maybe helpful for anyone else.
I had a similar problem with Visual Studio Code and its Intellisense C++ extension.
It didn't work because (on Windows 10) you can use 'fsutil' to change directories to be case sensitive.
Don't do that to SysGCC's directory and the checkout to 'case sensitive', it prevents the VS code plugin from successfully finding the source files.
We have a C_Cpp.caseSensitiveFileSupport setting you can change to "enabled" if you need to use case sensitive directories/files on Windows (Linux/Mac are already case sensitive by default).
Activity
jophippe commentedon Sep 19, 2017
According to #735, it looks like sshfs mounts that are too large will fail to be searched. You could try using a smaller mount and see if that works
jordangarside commentedon Sep 19, 2017
Gotcha, thanks a lot Jonathan Phippen (@jophippe)
I should have searched for that first, my bad.
sean-mcmanus commentedon Sep 19, 2017
Jordan Garside (@jordangarside) #735 was with Mac and the file APIs are different. Did using a smaller mount fix the issue?
jordangarside commentedon Sep 19, 2017
I'm going to try a smaller mount today Sean McManus (@sean-mcmanus) . I'll post here with the results.
jordangarside commentedon Sep 19, 2017
Sean McManus (@sean-mcmanus) Just tried a 50GB mount and still had the same issue. Strangely, it looks like IntelliSense is still loading because I get the
Configure includePath for better IntelliSense results.message (this happens for both mount sizes), but it doesn't detect the import errors.There are also no problems reported in the console.
sean-mcmanus commentedon Sep 19, 2017
Which winsshfs are you using? This one: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/win-sshfs/win-sshfs-0.0.1.5-setup.exe ?
jordangarside commentedon Sep 19, 2017
Sean McManus (@sean-mcmanus) https://github.com/Foreveryone-cz/win-sshfs/releases/tag/1.6.1
sean-mcmanus commentedon Sep 19, 2017
https://github.com/Foreveryone-cz/win-sshfs/releases/download/1.6.1/WinSSHFS-1.6.1.13-devel.msi doesn't install on any of my machines. Gives a couple errors: 2503, 2502. Are you using something else to install it?
jordangarside commentedon Sep 19, 2017
I'm using that MSI to install.
I think you also need to have Dokany installed before running the MSI.
sean-mcmanus commentedon Sep 19, 2017
Yeah, I have 1.0.5.1000 of Dokan: https://github.com/dokan-dev/dokany/releases/download/1.0.5/DokanSetup-1.0.5.1000.exe .
jophippe commentedon Sep 19, 2017
Okay, I just set up an sshfs connection using the 4every1 edition 1.5.12.8 and Dokany 0.7.4. I set up a folder on the mount, added an include, and it didn't show an error, just like yours. When I hover over the include, I get the message "FE 'Compiler exited with error - No IL available'". Do you get the same message Jordan Garside (@jordangarside)?
1 remaining item
jophippe commentedon Sep 19, 2017
Okay. The compiler failing is almost certainly the cause of the missing squiggles. I'll throw a debugger on there and see if this is a simple fix. Thanks for reporting this issue Jordan Garside (@jordangarside)
jordangarside commentedon Sep 20, 2017
Great, thanks guys!
barberdt commentedon Nov 2, 2017
Not sure if it's 100% related, but trying to get some feedback regarding the issues I've mentioned here microsoft/vscode#13665. I'm using VSCode, latest build (insiders has the same issue as well) on MacOS with a 1.2G SSHFS mounted directory. Intellisense and autocomplete are completely non-existent. FWIW, I'm mostly editing JS. It's quite frustrating given how much I love the editor (and that Atom won't even handle opening the directory), but having no autocomplete is...painful. Happy to provide any more info that's relevant. This should likely be an issue for anyone else who has to work on a monorepo hosted in a dev VM using SSHFS such that the files don't stay on the local machine.
garyng commentedon May 8, 2019
Is there any updates for this?
I got the same error while hovering over the includes:
Edit: the error seems to be similar to #1694
kasvith commentedon Sep 6, 2019
Having the same issue
Michanne commentedon Jul 13, 2020
I get this issue when trying to add a WSL-created directory as an include path. Create any directory from WSL and try to use it as an include path, giving the error:
Unable to retrieve file system information for xxx. error = -1The directory works fine, is not corrupted, files can be accessed as normal from the file explorer as well as VSCode, but completely breaks the Intellisense apparently. Makes it impossible to use for anything related to WSL
sean-mcmanus commentedon Jul 13, 2020
Micah (@Michanne) Are you using WSL2? Are you using the Remote - WSL extension to the connect? That is the recommended method.
Michannne commentedon Jul 16, 2020
Sean McManus (@sean-mcmanus) No not using WSL2, and I tried both with the Remote extension and also just creating a fresh project and adding a WSL folder to the browse.path or includePath depending on the engine.
I was able to resolve this issue another way, I create a folder for my repos by symlinking a C:/ drive folder, i.e. ~/repos -> /mnt/c/repos.
Like this, I am able to use intellisense on the Windows-side. Otherwise, if the directory is located in the rootfs/ of the WSL installation, it won't work, regardless of permissions. Intellisense can't read any directory in rootfs/
pobinger commentedon Feb 28, 2023
Not an answer, but maybe helpful for anyone else.
I had a similar problem with Visual Studio Code and its Intellisense C++ extension.
It didn't work because (on Windows 10) you can use 'fsutil' to change directories to be case sensitive.
Don't do that to SysGCC's directory and the checkout to 'case sensitive', it prevents the VS code plugin from successfully finding the source files.
sean-mcmanus commentedon Feb 28, 2023
We have a C_Cpp.caseSensitiveFileSupport setting you can change to "enabled" if you need to use case sensitive directories/files on Windows (Linux/Mac are already case sensitive by default).