jiebi/CodeConvo huggingface dataset:
Code change:
In version 0.10.1 it is no longer possible to write to the root of a drive (which worked up to 0.9.1). When trying to save to e.g. , the following error message appears: Tested on Windows 7 Ultimate and Windows 10 Professional, US language, German region settings.
are you sure you can save there, can you try with nodepad?
Yes, I can write a text file with notepad. And I also tried other drives. What I found out in the meantime is that this happens only when creating a new file. Opening, editing and saving an existing file works correctly.
so you do Ctrl+N, type something and then try to save it to r: from the windows save dialog?
Exactly. The error message appears trying to use Save, Save As or (when creating multiple files), Save All.
is R: some drive created with subst or a real physical drive? I assume it is not the root drive where windows is installed?
R: is a RAM disk - so I suspected this to be the problem at first. That's why I checked on other, "real" drives (except the system drive C:), and I can reproduce the behavior.
What I'm not sure about is why VSCode is trying to run at all. When I do this from a command line (), I get an "Access is denied" there as well - which doesn't surprise me.
It actually tries to create the root path :) If you run VS Code as non-admin, it won't even let you try to save to but if you run VS Code as admin, it will let you try but fails on creating . !
Thanks, will look into it!
This looks like a bad regression in (). It relies on the EEXIST error but when reaching the root drive, it ends in EPERM. I think you touched this function last.
As of now, 0.10.8-insider build run as an administrator lets you save to D:<filenameAs far as I can see, this is truly closed.

Related discussion:
text: import paths = require('vs/base/common/paths'); import { dirname, join } from 'path'; import { nfcall } from 'vs/base/common/async'; import fs = require('fs'); <ins> export function isRoot(path: string): boolean { return path === dirname(path); } </ins> export function readdir(path: string): TPromise<string[]> { return nfcall(extfs.readdir, path); }
Code change:
In version 0.10.1 it is no longer possible to write to the root of a drive (which worked up to 0.9.1). When trying to save to e.g. , the following error message appears: Tested on Windows 7 Ultimate and Windows 10 Professional, US language, German region settings.
are you sure you can save there, can you try with nodepad?
Yes, I can write a text file with notepad. And I also tried other drives. What I found out in the meantime is that this happens only when creating a new file. Opening, editing and saving an existing file works correctly.
so you do Ctrl+N, type something and then try to save it to r: from the windows save dialog?
Exactly. The error message appears trying to use Save, Save As or (when creating multiple files), Save All.
is R: some drive created with subst or a real physical drive? I assume it is not the root drive where windows is installed?
R: is a RAM disk - so I suspected this to be the problem at first. That's why I checked on other, "real" drives (except the system drive C:), and I can reproduce the behavior.
What I'm not sure about is why VSCode is trying to run at all. When I do this from a command line (), I get an "Access is denied" there as well - which doesn't surprise me.
It actually tries to create the root path :) If you run VS Code as non-admin, it won't even let you try to save to but if you run VS Code as admin, it will let you try but fails on creating . !
Thanks, will look into it!
This looks like a bad regression in (). It relies on the EEXIST error but when reaching the root drive, it ends in EPERM. I think you touched this function last.
As of now, 0.10.8-insider build run as an administrator lets you save to D:<filenameAs far as I can see, this is truly closed.

Related discussion:
text: return TPromise.wrapError<boolean>(err); }); <ins> if (isRoot(path)) { return TPromise.as(true); } </ins> return mkdir().then(null, (err: NodeJS.ErrnoException) => { if (err.code === 'ENOENT') { return mkdirp(dirname(path), mode).then(mkdir);
Code change:
I can confirm this happens for me as well. I am using Mac OS X. The operating system's display scaling is off (i.e. 1:1). I have been experimenting and it seems as though the bug is that the right click menu is displayed according to the cursor position, but this calculation is not adjusted to take into account zoom. The reason I say this is because if I right click near the top left of the editor, the cursor is quite close to the top left of the menu. But if I right click near the bottom right of the editor, the cursor is much further away from the top left of the menu. The misalignment is proportional to the distance from the top left of the editor.

Related discussion:
text: import {IMessageService} from 'vs/platform/message/common/message'; import {IKeybindingService} from 'vs/platform/keybinding/common/keybindingService'; <del> import {remote} from 'electron'; </del> <ins> import {remote, webFrame} from 'electron'; </ins> export class ContextMenuService implements IContextMenuService {
Code change:
I can confirm this happens for me as well. I am using Mac OS X. The operating system's display scaling is off (i.e. 1:1). I have been experimenting and it seems as though the bug is that the right click menu is displayed according to the cursor position, but this calculation is not adjusted to take into account zoom. The reason I say this is because if I right click near the top left of the editor, the cursor is quite close to the top left of the menu. But if I right click near the bottom right of the editor, the cursor is much further away from the top left of the menu. The misalignment is proportional to the distance from the top left of the editor.

Related discussion:
text: x = pos.x; y = pos.y; } <ins> let zoom = webFrame.getZoomFactor(); x *= zoom; y *= zoom; </ins> menu.popup(remote.getCurrentWindow(), Math.floor(x), Math.floor(y));
Code change:
I can confirm this happens for me as well. I am using Mac OS X. The operating system's display scaling is off (i.e. 1:1). I have been experimenting and it seems as though the bug is that the right click menu is displayed according to the cursor position, but this calculation is not adjusted to take into account zoom. The reason I say this is because if I right click near the top left of the editor, the cursor is quite close to the top left of the menu. But if I right click near the bottom right of the editor, the cursor is much further away from the top left of the menu. The misalignment is proportional to the distance from the top left of the editor.

Related discussion:
text: }) .done(null, e => this.messageService.show(severity.Error, e)); } <del> } </del>  No newline at end of file <ins> } </ins>
Code change:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help

Related discussion:
text: .pipe(util.cleanNodeModule('oniguruma', ['binding.gyp', 'build/**', 'src/**', 'deps/**'], ['**/*.node'])) .pipe(util.cleanNodeModule('windows-mutex', ['binding.gyp', 'build/**', 'src/**'], ['**/*.node'])) .pipe(util.cleanNodeModule('native-keymap', ['binding.gyp', 'build/**', 'src/**', 'deps/**'], ['**/*.node'])) <ins> .pipe(util.cleanNodeModule('windows-foreground-love', ['binding.gyp', 'build/**', 'src/**'], ['**/*.node'])) </ins> .pipe(util.cleanNodeModule('gc-signals', ['binding.gyp', 'build/**', 'src/**', 'deps/**'], ['**/*.node', 'src/index.js'])) .pipe(util.cleanNodeModule('pty.js', ['binding.gyp', 'build/**', 'src/**', 'deps/**'], ['build/Release/**']));
Code change:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help

Related discussion:
text: "from": "vscode-textmate@2.2.0", "resolved": "https://registry.npmjs.org/vscode-textmate/-/vscode-textmate-2.2.0.tgz" }, <ins> "windows-foreground-love": { "version": "0.1.0", "from": "windows-foreground-love@0.1.0", "resolved": "https://registry.npmjs.org/windows-foreground-love/-/windows-foreground-love-0.1.0.tgz" }, </ins> "windows-mutex": { "version": "0.2.0", "from": "windows-mutex@>=0.2.0 <0.3.0",
Code change:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help

Related discussion:
text: } }, "optionalDependencies": { <ins> "windows-foreground-love": "0.1.0", </ins> "windows-mutex": "^0.2.0", "fsevents": "0.3.8" }
Code change:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help

Related discussion:
text: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'windows-foreground-love' { export function allowSetForegroundWindow(pid?: number): boolean; } </ins>  No newline at end of file
Code change:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help

Related discussion:
text: export interface ILaunchService { start(args: ParsedArgs, userEnv: IProcessEnvironment): TPromise<void>; <ins> getMainProcessId(): TPromise<number>; </ins> } export interface ILaunchChannel extends IChannel { call(command: 'start', arg: IStartArguments): TPromise<void>; <ins> call(command: 'get-main-process-id', arg: null): TPromise<any>; </ins> call(command: string, arg: any): TPromise<any>; }
Code change:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help

Related discussion:
text: constructor(private service: ILaunchService) { } call(command: string, arg: any): TPromise<any> { <del> const { args, userEnv } = arg as IStartArguments; </del> switch (command) { <del> case 'start': return this.service.start(args, userEnv); </del> <ins> case 'start': const { args, userEnv } = arg as IStartArguments; return this.service.start(args, userEnv); case 'get-main-process-id': return this.service.getMainProcessId(); </ins> } } }