TypeScript: TypeScript file watcher holds onto folders and causes EPERM

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

  • VS Code Version: Version: 1.77.3 (user setup) Commit: 704ed70d4fd1c6bd6342c436f1ede30d1cff4710 Date: 2023-04-12T09:16:02.548Z Electron: 19.1.11 Chromium: 102.0.5005.196 Node.js: 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0.19044 Sandboxed: No

  • OS Version: Windows 10 professional

Steps to Reproduce:

  1. just rename or moving files/folder, and this problem occasionally.
  2. After restart vscode, the rename/moving operation completed automatically.
  3. I’m pretty sure the rename/moving operation act normally in file explorer

I have checked all below items, so I’m pretty sure there is no other process using these files except vs code.

  1. no other window opened.
  2. no vscode extension runing because I uninstall them all.
  3. only vscode using the file, It’s weird because there are two records. image

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 4
  • Comments: 54 (17 by maintainers)

Most upvoted comments

I also had this problem, but I found that setting typescript.tsserver.useSyntaxServer to always solved the problem. I guess there are too many files in the project directory.

I have the same problem on VSCode 1.83 with my NextJS project. Some folders are moving correctly but others can throw error. As soon as the TS server starts the folders are locked. If you move files and folders before the server starts, it will work. This pisses me off terribly and prevents me from refactoring the project. Because TS server gives the possibility to update imports automatically, without it you have to update them manually. I don’t know who invented this. You can turn off all extensions, you can try the insider build, but it’s all useless, the errors remain. I’m using latest Windows 11.

image

try in settings.json:

"typescript.tsserver.watchOptions": {
        "watchFile": "fixedChunkSizePolling"
    },

Thanks, I suspect the typescript extension to install a watcher on dedicated folders that on Windows may result in folder locking.

Time goes by and the problem is still relevant. The only thing I found to avoid restarting VSCode every time is to go to the TypeScript file and open Command Palette and find “TypeScript: Restart TS Server”, this option will not appear if your cursor is not focused on the TypeScript file. And while it is restarting you can rename your file or folder, but if it restarts before you rename it will lock your files or folder again and of course there will be no automatic import update. 😄

image

Then I suggest to file an issue to the tool you are running that results in the file lock.

Yes I agree, thank you for looking into it though.

I just tested renaming a directory which has many subdirectories with many files and it failed just like it’s been failing. I tested with the typescript.tsserver.experimental.useVsCodeWatcher enabled and not and both way failed while running a nextjs (v12.3.1) project.

My environment:

Version: 1.89.0-insider (user setup) Commit: 50a6f4f200c5a33f47997eb6a8966e50cf219e21 Date: 2024-04-12T05:50:19.038Z Electron: 28.2.8 ElectronBuildId: 27744544 Chromium: 120.0.6099.291 Node.js: 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0.19045

Directories (I tried renaming the Componentss directory):

image

But using PowerToys File Locksmith it says that the directory is being held by node.exe

To clarify, typescript.tsserver.experimental.useVsCodeWatcher is not enabled by default, so you need to change settings as well as being on latest.

👋 we are experimenting with using VS Codes core file watcher in the TypeScript extension (microsoft/vscode#208872). There is a new setting typescript.tsserver.experimental.useVsCodeWatcher available starting with todays VS Code insider release. Curious if people could try it out by enabling it and seeing if the EPERM issue gets better. In my testing [#54087 (comment)]

Latest Windows 11. Latest VSCode Insiders. With TypeScript Nightly or without it. Project based on Nx, TypeScript, ReactJS, NextJS. Same result.

image image

👋 we are experimenting with using VS Codes core file watcher in the TypeScript extension (https://github.com/microsoft/vscode/issues/208872). There is a new setting typescript.tsserver.experimental.useVsCodeWatcher available starting with todays VS Code insider release. Curious if people could try it out by enabling it and seeing if the EPERM issue gets better. In my testing https://github.com/microsoft/TypeScript/issues/54087#issuecomment-2028554228 seems to be resolved at least.

It is worth noting that this is a change that may come with other bugs and we are happy for feedback and early adopters 🙏 . Please report issues at https://github.com/microsoft/vscode/issues

You can give our preview releases a try from: https://code.visualstudio.com/insiders/

try in settings.json:

"typescript.tsserver.watchOptions": {
        "watchFile": "fixedChunkSizePolling"
    },

Works perfect, now I am able to rename or delete files/folders. But the drawback is that auto imports dont work anymore, But I can do it my self… Thanks for the solution sir.

I also had this problem, but I found that setting typescript.tsserver.useSyntaxServer to always solved the problem. I guess there are too many files in the project directory.

This unlocks the files but unfortunately it doesn’t auto-update the imports.

I have the same problem on VSCode 1.83 with my NextJS project. Some folders are moving correctly but others can throw error. As soon as the TS server starts the folders are locked. If you move files and folders before the server starts, it will work. This pisses me off terribly and prevents me from refactoring the project. Because TS server gives the possibility to update imports automatically, without it you have to update them manually. I don’t know who invented this. You can turn off all extensions, you can try the insider build, but it’s all useless, the errors remain. I’m using latest Windows 11. image

I have the exact same experience

Same here