Incorrect usage of URI#path.toString() on Windows

[msujew]

Description

This issue is meant to collect incorrect usages of displaying URI strings on Windows systems. Simply calling URI#path.toString() usually results in incorrectly formatted paths. See #10591. See also the following as an example:

• file-tree-widget.tsx
• workspace-frontend-contribution.ts
• search-in-workspace-result-tree-widget.tsx
• scm-tree-widget.tsx and here
• resource-property-view-tree-widget.tsx
• preferences-contribution.ts
• problem-decorator.ts
• location-renderer.tsx and here
• editor-widget-factory.ts
• debug-source.ts
• label-provider.ts
• preference-file-input.ts

Additional Information

• Operating System: Windows
• Theia Version: 1.23.0

[tsmaeder]

@msujew what's the problem with calling uri.path.toString()? Can you give an example that shows the problem?

[tsmaeder]

Also, doing a workspace find for ".path.toString()" reveals many more occurrences than the above. How did you come about the list above?

[msujew]

@tsmaeder, calling URI.path.toString() on posix systems (non-Windows) is completely fine. Doing the same on Windows leads to weird file paths, which are likely not to be accepted by the system:

const uri = new URI("file://c:\\path\\to\\file");
uri.path.toString(); // yields "/c:/path/to/file

Although / are fine on Windows, the leading slash isn't really valid. This also leads to issues where certain parts of the backend operate on the direct fs based path presentation, while some others work on the URI based presentation.

Also, doing a workspace find for ".path.toString()" reveals many more occurrences than the above. How did you come about the list above?

Not all path.toString() calls are directly used. Most of the time we do something like this:

const path = uri.path.toString();
... // somewhere later
const uriPath = new URI(path);

Which is fine, but once we start interaction with the file system or displaying these paths to the user, we need to convert them to the correct OS presentation.