Cancel file operations from opening an editor when closing it

[solesensei]

Issue Type: Bug

Found a bug.
When you clicked to open huge file, for ex. 1.5 GB txt, and then immediately closed it - VS Code will try to open it anyway, RAM will be overflow, and Studio crashes.

VS Code version: Code 1.26.1 (493869e, 2018-08-16T18:38:57.434Z)
OS version: Windows_NT x64 10.0.17134

[rebornix]

@solesensei do you still run into this issue when you run code --max-memory=4096?

[solesensei]

@rebornix no, 4096 is okay for huge files, i talk about opening process, i have no needs in opening that file.

For me problem is:
when i opened huge file (115m lines), and then clicked close - vs code was continuing reading from my drive in background and overloading RAM. Reading process wasn't killed.

[solesensei]

@rebornix
i think that reading process will be closed only after opening whole file in background (=loaded it in RAM)

[rebornix]

@solesensei thanks for helping nail down the root cause ;)

[rebornix]

@bpasero may I have some help from your Electron expertise?

[rebornix]

Unluckily I can't reproduce this issue on my Windows box.

[bpasero]

We are reading the file async and not sync so I would think that closing VSCode stops node.js from reading the file but if that is not true the only fix I can see is pushing down a cancellation token all the way (which seems like a workaround for node.js doing the right thing though).

[rebornix]

By reading https://nodejs.org/api/fs.html#fs_fs_readfile_path_options_callback and IMHO the potential fix is sending AbortSignal

const controller = new AbortController();
const signal = controller.signal;
fs.readFile(fileInfo[0].name, { signal }, (err, buf) => {
  // ...
});
// When you want to abort the request
controller.abort();

Though I'm not sure if it will really kill the OS process as it's OS dependent. There isn't anything we can do in the text buffer so leave to @bpasero or @deepak1556 to decide if we want to have any fix for it.;

[bpasero]

This requires cancellation support on the level of the IFileSystemProvider but I am not sure it is worth pushing for it...

//cc @jrieken

[bpasero]

Updated the title from the duplicate #146912. If we could introduce a setting for the maximum file size a user can open, we should use that information here:

vscode/src/vs/platform/files/common/fileService.ts

Line 552 in 2dbc994

const fileStat = await statPromise;

To cancel the reading and throw an error so that upstream component can show a generic editor.

[chickenSandwich]

This is a big issue for me because I am creating JSON files that have binary blobs that are large. If I click on the file in Explorer the editor will try to preview the file. There is no way to cancel the process of trying to preview/open the file and VSCode eventually displays a dialog asking if I want to close the editor or continue waiting. I cannot open the Developer Tools or the Process Explorer to terminate the tab that is trying to preview/open the file. I have waited for up to 30 minutes, and the file never finishes and the editor is unusable.
The worst part is that when you re-open that folder in VSCode, the same process repeats. The only way that I have been able to get back to work is by deleting the workspaceStorage folder (/home/user/.config/Code/User/workspaceStorage).

It would be nice if I could cancel/abort the preview/open process.

[bpasero]

The setting workbench.editorLargeFileConfirmation will help here. Set it to a lower value to match the file sizes you encounter this with and editors will not just open until you confirm.

[chickenSandwich]

The setting workbench.editorLargeFileConfirmation will help here. Set it to a lower value to match the file sizes you encounter this with and editors will not just open until you confirm.

Thank-you. I had already changed that setting to save myself the trouble from this issue, however, I feel that it would be a valuable addition to VSCode to allow for the cancellation of a long running preview/open process.

[johnyv276]

this setting doesn't help on custom editors
I opened an issue on the topic at the extension vscode-parquet-viewer
look at the response from the extonsion's dev
dvirtz/vscode-parquet-viewer#144