Replace VSCode.Uri.path with fsPath when reading SVG files

[gquerret]

According to the documentation, fsPath should be used instead of path when reading files on disk. An issue has been reported by users of a fork of SonarLint for VSCode for a custom language, where it was impossible to open the rules description view. Developer console showed this message:

ERR [Extension Host] Notification handler 'sonarlint/showRuleDescription' failed with message: ENOENT: no such file or directory, open 'C:\c:\Users\UserName\.vscode\extensions\riversidesoftware.sonarlint-abl-4.14.99002\images\type\code_smell.svg'

Note the double c:\ at the beginning of the path. The problem doesn't happen in all VS Code environments, but switching to the recommended attribute fsPath solves the problem. I assume the problem can also happen in the standard SonarLint plugin, hence the PR.

• Please explain your motives to contribute this change: what problem you are trying to fix, what improvement you are trying to make
• Use the following formatting style: SonarSource/sonar-developer-toolset
• Provide a unit test for any code you changed
• If there is a JIRA ticket available, please make your commits and pull request start with the ticket ID (SLVSCODE-XXXX)

[jblievremont]

Hello, thank you for your contribution!

You mentioned that the problem doesn't happen in all VS Code environments, would it be possible for you to share any hint you may have about the type(s) of environment(s) where this happens? This could help us write an automated test for this.

I created a ticket that we'll address in an upcoming release.

[gquerret]

When the issue was reported to me, I initially tried to reproduce on my work machine, but everything was working as expected (Windows 11 Pro, latest VS Code version). Then it tried again the next day with my machine at home, and it failed. And it now fails on both machines...

So I just created a new VS Code profile, with SonarQube as the only plugin. VS Code details:

Version: 1.96.4 (user setup)
Commit: cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba
Date: 2025-01-16T00:16:19.038Z (2 wks ago)
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.26100

I can now consistently reproduce the issue on one of my Java project connected to a private SonarQube instance, while there's no issue when using another Java project connected to SonarCloud.

[jblievremont]

Thanks for the additional details!

I was able to reproduce the issue with the latest VSCode and SonarQube IDE on a Windows 10 VM, in connected mode with a SonarQube server in "Standard Experience Mode". We'll make sure to prioritize the fix.