Support to detect file links in output

[juxeii]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.67.0 (system setup)
• OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce:

1. Open a workspace folder, say /home/juxeii/projects/myproject
2. Create an empyt file, say gtestLog_testfoo and save this under /home/juxeii/projects/myproject and under /home/juxeii
3. Create a simple vsc extension and write both file paths to an output channel like so:

const outputChannel = vscode.window.createOutputChannel('MyExt');
const testfileuriBad = vscode.Uri.file(path.join('/home/juxeii', 'gtestLog_testfoo'));
outputChannel.appendLine(testfileuriBad);
const testfileuriGood = vscode.Uri.file(path.join('/home/juxeii/projects/myproject, 'gtestLog_testfoo'));
outputChannel.appendLine(testfileuriGood);

On my extension it looks like this

[5/10/2022, 12:57:31] INFO: Log file: file:///home/juxeii/projects/myproject/gtestLog_testfoo
[5/10/2022, 12:57:31] INFO: Test file file:///home/juxeii/gtestLog_testfoo

The output channel provides two file link, both of which I can click.
But only the first link file:///home/juxeii/projects/myproject/gtestLog_testfoo opens the file, while the second fails:

This occurs both when working with remote ssh on wsl2 on windows, and with a remote linux machine.
Is this intended behavior not letting open files outside the workspace?

The error log in the output window gives Log (Window)

[2022-05-10 13:21:40.864] [renderer3] [error] Error: File not found
    at g.handleSetInputError (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2701:95592)
    at async g.setInput (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2701:94832)
    at async doSetInput (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2699:6429)
    at async doOpenEditor (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2699:4791)
    at async d.openEditor (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2699:3783)
    at async vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2906:16950
    at async C.doOpenCodeEditor (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:1360:31342)
    at async m.open (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:594:51701)
    at async open (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:594:53162)

EDIT: open the folder /home/juxeii as workspace root, and I can open the file again. This confirmes that somehow the workspace root is in play here, which has a problem with links in the output window to files outside the workspace.

[newspore]

I actually have the Same problem but this is also Happening when the Problems try to Redirect to the Editor.
It display a "The editor could not be Opened because the File was not Found" Error.
When Checking the Logs:
[2022-05-25 14:26:36.240] [renderer1] [error] Error: File not found at g.handleSetInputError (vscode-file://vscode-app/c:/Users/lgarcia/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2701:95592) at async g.setInput (vscode-file://vscode-app/c:/Users/lgarcia/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2701:94832) at async doSetInput (vscode-file://vscode-app/c:/Users/lgarcia/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2699:6429) at async doOpenEditor (vscode-file://vscode-app/c:/Users/lgarcia/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2699:4791) at async d.openEditor (vscode-file://vscode-app/c:/Users/lgarcia/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2699:3783) at async vscode-file://vscode-app/c:/Users/lgarcia/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2906:16950

So I do have a Workspace with only 1 Folder and the Extension I use are for Saleforce Extension Pack.
Now doing some debugging I did also find that the Folder that is being Tryied to Display Stores on the VS Root Folder rather than taking the Relative Path within the Workspace.
Openning in File Explorer command does also crash and cannot actually show or display the File in question and when I follow the Suggestion of Created a new File it did show me that the file was created on C://relativePath

[bpasero]

Does this reproduce when not using remote? I wonder if we need to properly convert file paths for opening when clicking on the output because they originate from the remote and cannot be opened locally. I.e. a file link that gets written to from a remote should result in a vscode-remote link for opening?

[juxeii]

@bpasero Yes, it is not dependent on any remote setting. Just create an simple extension with an output channel and write two uri's to it. One within project root and one outside.

[bpasero]

I wonder if something with the paths is messed up, when you click "Create File" where does it store the file to?

[juxeii]

I recall, it created it locally(in the remote setting) and what was also weird, it also changed from "/" to "" as path delimiter.
Again, I think the output window parser has a problem with files outside workspace root.

[bpasero]

I cannot reproduce, even from an empty window, I can open both paths. My extension code:

const outputChannel = vscode.window.createOutputChannel('MyExt');
const testfileuriBad = vscode.Uri.file(path.join('/Users/bpasero/', 'gtestLog_testfoo')).toString();
outputChannel.appendLine(testfileuriBad);
const testfileuriGood = vscode.Uri.file(path.join('/Users/bpasero/Desktop', 'gtestLog_testfoo')).toString();
outputChannel.appendLine(testfileuriGood);

I have a file gtestLog_testfoo both in /Users/bpasero/ and /Users/bpasero/Desktop.

[bpasero]

[juxeii]

I don't know how to help. I have created an empty extension.
Here is extension.ts

// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
import * as vscode from 'vscode';
import * as path from 'path'

// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
export function activate(context: vscode.ExtensionContext) {

    const outputChannel = vscode.window.createOutputChannel('MyExt');
    const testfileuriBad = vscode.Uri.file(path.join('/home/juxeii/projects/gtest-cmake-example', 'gtestLog_testfoo')).toString();
    outputChannel.appendLine(testfileuriBad);
    const testfileuriGood = vscode.Uri.file(path.join('/home/juxeii/projects', 'gtestLog_testfoo')).toString();
    outputChannel.appendLine(testfileuriGood);
}

// this method is called when your extension is deactivated
export function deactivate() { }

The extension project lives in /home/juxeii/projects/path in an Ubuntu WSL2.
When I hit F5 to debug the extension, a new VSC window opens with a project living in
/home/juxeii/projects/gtest-cmake-example

I created dummy files gtestLog_testfoo both under /home/juxeii/projects/gtest-cmake-example and /home/juxeii/projects.
I can only open the first one form the output window.

Do you have some Windows machine with WSL2 to test?

[bpasero]

Thanks for the steps, so it is happening in a remote WSL environment. I suspect that maybe we do some special mapping of the paths for the workspace folder so that files outside of the workspace cannot be opened, but I let Martin chime in as well.

[juxeii]

Just for the records: it is not only happening in a WSL environment, but it is the same issue in a remote SSH setting.

[sandy081]

I wonder if it is output channel related issue because the files in workspace are being opened. I suspect some where inside while opening the file there could be a validation to not to allow file outside workspace?

[bpasero]

I am able to reproduce and believe this is a bug in how we transform URLs. In my testing, only a link that points into a file inside the workspace is being converted to vscode-remote, while links outside the workspace remain file scheme. The link detector should not make assumptions about the location of the file imho.

[alexdima]

In my testing, only a link that points into a file inside the workspace is being converted to vscode-remote, while links outside the workspace remain file scheme.

@bpasero The URI converter converts all URIs unrelated if they belong in a workspace or not. I think the difference is explained by this special casing of workspace folders in the output link computer.

[bpasero]

@alexdima 🤔 but the link is there even for the non-workspace case, so link detection seems to work, but maybe we do the rewriting conditionally.

[bpasero]

Oh I see, the links are indeed different:

• the first one is correctly detected as a link inside the workspace and properly handled
• the second one is just detected with our default link detector (the same that is used for web sites for example)

As such it makes sense that for the second link we just try to open it.

[bpasero]

Turning into a feature as this works as intended currently. We need to expand the output link detection to handle file links if we want to support this scenario.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[juxeii]

Turning into a feature as this works as intended currently. We need to expand the output link detection to handle file links if we want to support this scenario.

Is there any reason why it should not be supported? At least a little documentation about this behaviour would be needed.

[bpasero]

Is there any reason why it should not be supported?

Nope, no reason I can think of.

[juxeii]

Just asking, since it is declared as feature now, which means it is dependant on upvotes.

[bpasero]

👍

[juxeii]

👍