Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS Code acquires lock in node_modules/.staging, making NPM freeze for about 30 seconds #29204

Closed
alshain opened this issue Jun 21, 2017 · 6 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug *duplicate Issue identified as a duplicate of another issue(s)

Comments

@alshain
Copy link

alshain commented Jun 21, 2017

  • VSCode Version: Code 1.13.1 (379d2ef, 2017-06-14T18:21:47.485Z)
  • OS Version: Windows_NT ia32 10.0.15063
  • Extensions:
Extension Author Version
project-manager alefragnani 0.18.1
better-toml bungcip 0.2.0
vsc-rustfmt Connorcpu 0.1.0
vscode-eslint dbaeumer 1.2.11
githistory donjayamanne 0.2.0
python donjayamanne 0.6.5
EditorConfig EditorConfig 0.9.3
tslint eg2 0.15.0
vscode-rust kalitaalexey 0.4.0
PowerShell ms-vscode 1.4.0
debugger-for-chrome msjsdiag 3.1.4
vscode-docker PeterJausovec 0.0.16
java redhat 0.6.0
vscode-icons robertohuertasm 7.9.0
vscode-lldb vadimcn 0.5.1
JavaScriptSnippets xabikos 1.4.0
Material-theme zhuangtongfa 2.8.8

Steps to Reproduce:

  1. Open VS Code, edit TSX file
  2. leave editor open, run "node install" in project
  3. npm install takes over a minute longer than when not running VS Code,

NPM often hangs on a line such as this:

[       ...........] - extract:fsevents: verb lock using C:\Users\alshain\AppData\Roaming\npm-cache\_locks\staging-3d5cc763a76e1aa2.lock for c:\Users\alshain\Documents\typescript\node_modules\.staging

After a long wait time, npm will output something like (always EPERM, rename):

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Error: EPERM: operation not permitted, rename 'c:\Users\alshain\Documents\typescript\.staging\fsevents-ca317142\node_modules\boom' -> 'c:\Users\alshain\Documents\typescript\node_modules\.staging\boom-1ae2831a'

I'm not sure whether this is random, but VS Code seems not to acquire a lock in .staging very often when editing the settings for instance.

I was also able to confirm VS Code having a handle in .staging using process explorer a few times.

Once, I also got some kind of info popup in VS Code about it not being able to load completions or type definitions or whatever and it also mentioned a file inside the node_modules/.staging directory.

The problem always goes away when closing VS Code.

Apparent fix: adding this to my user settings:

    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
       // Note the dot before the asterisk
        "**/node_modules/.*/**": true
    }

workspace settings

{
    "files.exclude": {
        "**/.git": true,
        "**/.svn": true,
        "**/.hg": true,
        "**/CVS": true,
        "**/.DS_Store": true,
        "node_modules/": true
    }
}

user settings

{
    "workbench.iconTheme": "vscode-icons",
    "window.zoomLevel": 0,
    "terminal.integrated.shell.windows": "C:\\WINDOWS\\Sysnative\\WindowsPowerShell\\v1.0\\powershell.exe"
}

my package.json

{
  "name": "typescript",
  "version": "0.1.0",
  "private": true,
  "homepage": ".",
  "dependencies": {
    "@blueprintjs/core": "^1.20.0",
    "@blueprintjs/datetime": "^1.17.0",
    "@types/classnames": "^2.2.0",
    "@types/jest": "^19.2.4",
    "@types/node": "^7.0.27",
    "@types/react": "^15.0.27",
    "@types/react-dom": "^15.5.0",
    "classnames": "^2.2.5",
    "es6-shim": "^0.35.3",
    "mobx": "^3.1.15",
    "mobx-react": "^4.2.1",
    "react": "^15.6.0",
    "react-addons-css-transition-group": "^15.6.0",
    "react-dom": "^15.6.0",
    "reflect-metadata": "^0.1.10"
  },
  "devDependencies": {
    "react-scripts-ts": "2.2.0"
  },
  "scripts": {
    "start": "react-scripts-ts start",
    "build": "react-scripts-ts build",
    "test": "react-scripts-ts test --env=jsdom",
    "eject": "react-scripts-ts eject",
    "tsc": "tsc"
  }
}
@mjbvz mjbvz self-assigned this Jun 21, 2017
@filipesilva
Copy link

Also suffering from this atm, it was driving me nuts. Trying out your workaround.

@dellinger
Copy link

I'm also seeing this

@aarndt
Copy link

aarndt commented Jun 26, 2017

I am experiencing this as well. NPM install works once VS Code is closed.

@mjbvz mjbvz added the bug Issue identified by VS Code Team member as probable bug label Jun 28, 2017
@mjbvz
Copy link
Collaborator

mjbvz commented Jun 28, 2017

Sounds similar to #28593 and #28013

If you are on windows and are running into this issue, please try using this tool to see which process is locking the .staging files. Please share all the command line arguments from the process since there may be a number of processes named "vscode-*"

@filipesilva
Copy link

@mjbvz I tried using that tool but by the time the error occurs, .staging isn't there anymore. The only process using node_modules seems to be Code.exe though.

C:\Users\kamik\work\ngo>npm i
[email protected] C:\Users\kamik\work\ngo
+-- [email protected]
+-- [email protected]
+-- [email protected]
+-- [email protected]
+-- [email protected]
`-- [email protected]

npm WARN [email protected] No repository field.
npm ERR! Windows_NT 10.0.15063
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "i"
npm ERR! node v6.10.3
npm ERR! npm  v3.10.10
npm ERR! path C:\Users\kamik\work\ngo\node_modules\.staging\tslint-1e1af323
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall rename

npm ERR! Error: EPERM: operation not permitted, rename 'C:\Users\kamik\work\ngo\node_modules\.staging\tslint-1e1af323' -> 'C:\Users\kamik\work\ngo\node_modules\tslint'
npm ERR!     at destStatted (C:\Users\kamik\AppData\Roaming\nvm\v6.10.3\node_modules\npm\lib\install\action\finalize.js:25:7)
npm ERR!     at C:\Users\kamik\AppData\Roaming\nvm\v6.10.3\node_modules\npm\node_modules\graceful-fs\polyfills.js:264:29
npm ERR!     at FSReqWrap.oncomplete (fs.js:123:15)
npm ERR!
npm ERR! Error: EPERM: operation not permitted, rename 'C:\Users\kamik\work\ngo\node_modules\.staging\tslint-1e1af323' -> 'C:\Users\kamik\work\ngo\node_modules\tslint'
npm ERR!     at Error (native)
npm ERR!  { Error: EPERM: operation not permitted, rename 'C:\Users\kamik\work\ngo\node_modules\.staging\tslint-1e1af323' -> 'C:\Users\kamik\work\ngo\node_modules\tslint'
npm ERR!     at destStatted (C:\Users\kamik\AppData\Roaming\nvm\v6.10.3\node_modules\npm\lib\install\action\finalize.js:25:7)
npm ERR!     at C:\Users\kamik\AppData\Roaming\nvm\v6.10.3\node_modules\npm\node_modules\graceful-fs\polyfills.js:264:29
npm ERR!     at FSReqWrap.oncomplete (fs.js:123:15)
npm ERR!
npm ERR! Error: EPERM: operation not permitted, rename 'C:\Users\kamik\work\ngo\node_modules\.staging\tslint-1e1af323' -> 'C:\Users\kamik\work\ngo\node_modules\tslint'
npm ERR!     at Error (native) parent: 'ngo-loader' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\kamik\work\ngo\npm-debug.log

C:\Users\kamik\work\ngo>handle64.exe node_modules

Nthandle v4.1 - Handle viewer
Copyright (C) 1997-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Code.exe           pid: 11224  type: File           494: D:\work\ngo\node_modules\make-error
Code.exe           pid: 11224  type: File           538: D:\work\ngo\node_modules

C:\Users\kamik\work\ngo>dir node_modules\.staging
 Volume in drive C is RED-13
 Volume Serial Number is ECEA-1B00

 Directory of C:\Users\kamik\work\ngo\node_modules

File Not Found

@mjbvz
Copy link
Collaborator

mjbvz commented Jul 5, 2017

Thanks for all the info. I believe I may have a handle on what is going wrong here. See: #28593 (comment)

Closing as a duplicate of #28593

@mjbvz mjbvz closed this as completed Jul 5, 2017
@mjbvz mjbvz added the *duplicate Issue identified as a duplicate of another issue(s) label Jul 5, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug *duplicate Issue identified as a duplicate of another issue(s)
Projects
None yet
Development

No branches or pull requests

6 participants