node_modules/@types cannot be deleted on Windows #29407
Comments
|
I also see this issue but I have |
|
Sometimes I see similar problem (but with random folders/files inside node_modules), closing vscode doesn't help, explorer shows unknown folder/file owner. Unmounting and then mounting volume helps. I think it's some ntfs bug. |
|
This is how I've been seeing this most of the time: |
|
Moving upstream as the lock does seem to be held by the TS Server. Here's the process I see with a handle to the |
weswigham
added
Bug
mjbvz
added
the
VS Code Priority
|
This really makes the experience bad on Windows, any time I git clean i need to reload the vscode window. |
|
I have investigated this and it seems like when built folder is deleted by gulp build, node doesn't notify us correctly and goes in bad state instead before executing "error" handler. used repro from: microsoft/vscode#68576 (comment) |
|
Yes, the permission errors are caused with some deletions. Thanks for your repro. |
sheetalkamat
removed
the
Needs Investigation
|
When I try to delete this folder, it tells me I require permission from the computer's administrator to make changes to the folder. I AM the computer's administrator. BUT THEN... I restarted my computer and the folder was gone. |
|
FWIW using this command before deleting |
|
So does reloading vscode or restarting your computer but this is still an annoying bug 😔 |
|
In the past couple months, a lot of people have started reporting this issue when working in our monorepo. If there's no quick fix, is there a PR that can be temporarily reverted to restore the old behavior? Or is there a way to downgrade the tsserver version used by VS Code IntelliSense? |
|
Similar to what @Tyriar said, I was only able to finally run |
I installed the current insiders build: But I am still struggling deleting node_modules: After a "Typescript: Restart TS Server" the delete works (or after closing VSC). I am a big fan of VSC. This is one of the few quirks (probably the only one) that constantly bogs me down. Sometimes it also happens when updating packages. Or when rebuilding local libraries which are installed with npm link. Or even when you want to delete or move directories in your project. "Restart TS Server" helps. But since TS immediately starts scanning files again it's a hit and miss. |
|
I'm pretty sure I hit this again after this was closed, I just might not be noticing it as much as I'm doing more development via remote ssh on a Linux VM. Before this closed I did verify launching VS Code, running yarn watch and waiting for intellisense followed by |
|
I faced the same issue, and closing the vscode helped me deleting the node_modules folder |
|
Doesn't help that the issue is closed in both the TypeScript repo and the vscode repo, despite people still being directed here |
|
Not sure if this is the same bug but I'm sure it's related. Sometimes checking out a branch fails halfway because VSCode has files open which leaves my working tree in an inbetween state and it's annoying to fix ( @sheetalkamat can we reopen this issue? It is clear that Electron 3.1.8 did not fix the issue (at least not completely).
|
|
This issue was for the TypeScript language service. You file lock might be from that, or it could be from any other plugin you're using, or it could also be from Electron itself as was the case above. It's important to determine which compenent is responsible first, to make sure you're reporting the issue in the right GitHub project, and give the maintainers something to investigate. Anecdotally I can say that VS Code has been working great for me so far since the Election fix. (Fingers crossed!) |
|
Same issue, behavior with Visual Studio 2019 (16.1.3) on windows 10, running npm script that calls rimraf on node_modules gives a permissions error on files in the |
|
This is definitely still happening, please reopen the issue. Version: 1.36.0-insider (user setup) I did a VS Code build (yarn watch), it failed with: Immediately after I restart TS server and ran |
|
See #32113 which sounds like it is not VS Code (electron) specific |
Yeah that's my issue. Same thing as this issue but I use VS2019, not VScode. I have a project it reliably happens on but it's private. Hard to reproduce in a new project and I don't have a ton of time to put into it. Could have something to do with switching branches, not sure. Or maybe npm link, via lerna. Or babel+webpack. Lots of variables. |
|
What version do I need to upgrade to in order to fix this? |
You don't |
|
For the record this is much more than just @types having an issue. If you leave vs code open for a while and update packages etc with npm update or npm install and then without anything open rimraf node_modules it will fail and will fail on other module deletes. Further even if no @types vscode won't delete the node_modules folder itself. Further, even rimrafing modules within the node_modules folder if you have opened a file that has an import statement from that module will cause the same issue: unlink error. This is chronic and really screwing with workflows and wasting time for devs and STILL exists 8/8/2019 in the latest vs code using angular as an example. |
|
@JohnGalt1717 This is an already closed issue pertaining to the TypeScript compiler service (and which turned out to be an Electron bug, not TypeScript). The errors definitely stopped happening for me after the fix, so I'm somewhat skeptical that TypeScript is the cause of your issue. Are you sure it's not caused by something else like one of your VSCode extensions, or your virus scanner, etc? Your issue is more likely to get fixed if you report it to the right GitHub project. |
|
safe mode with 0 extensions still causes it. I tried and they referred to this issue and closed it. |
|
I'm definitely still seeing this, both in VS Code and VS Pro, so it's not VS Code-specific. Since restarting TS Server helps, the issue looks like it should be in this repo. |
|
It's probably best to continue discussion in the open dupe issue #32113. They need reliable repro steps. |
|
this STILL happens with TS 3.7.2 and VSCODE 1.40.1 |
|
I also experience similar issues, ever since I started using VS Code, now I am on the version 1.41. It prevents me to delete folders inside the project dir. Distracts git, sometimes even fetch fails, while VS Code is running. |
|
Yes, I have this issue while using VSCode with projects, especially those involving javascript files. |
|
@sheetalkamat a year has passed since this bug was reported, and despite the electron bugfix it is clear that the issue is not completely resolved as my entire team still experiences this issue along with multiple other people reporting it here over the past few months. Please can we reopen this bug? |
|
@biltongza they're way too busy handling real issues with VScode like the santa hat on the settings cog |
|
This still exists as of August 2021. I'm having the same error messages as @nharrer and this is a major annoyance. |
|
This issue was not resolved for me, I am not using node, typescript, or windows. Just posting here since all other similar issues where closed with reference to 'upstream' i.e. this one. Running into it with a potential combination of other issues. See here: Azure/azure-functions-python-worker#1306 (comment). |
and others
Workaround: Run this command to release the lock on the file:
Issue Type: Bug
Probably related to automatic type acquisition. I've been seeing this frequently only on Windows:
This is what explorer tells me when I try to go to that folder:
When I close vscode, the
@typesfolder deletes itself.VS Code version: Code - Insiders 1.31.0-insider (e02e44464c02d617b98d0a3265bf5efef7794436, 2018-12-21T06:20:35.852Z)
OS version: Windows_NT x64 10.0.17763
System Info
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: enabled
surface_synchronization: enabled_on
video_decode: enabled
webgl: enabled
webgl2: enabled
Extensions (11)
(1 theme extensions excluded)
The text was updated successfully, but these errors were encountered: