npm install fails with "ENOENT: no such file or directory" on .DELETE files

[dkent600]

I'm opening this issue because:

• npm is failing for some reason I don't understand

What's going wrong?

This is happening to me more often than not. Example:

npm ERR! enoent ENOENT: no such file or directory, rename 'C:[...]\node_modules\rx' -> '[...]\node_modules.rx.DELETE'

It is a different file every time, sometimes doesn't happen at all, but when it does, always with [something].DELETE.

Turning off virus protection doesn't help.

Running npm cache clean -f, as administrator doesn't help

The problem has been getting steadily worse since a week or so ago, but seems somewhat random as to which file it will fail upon.

How can the CLI team reproduce the problem?

run npm install
wait for it to fail

npm-debug.log file: https://gist.github.com/dkent600/9cf97717cc3dbd553bea6c1a116145a7

supporting information:

• npm -v prints: v5.0.3
• node -v prints: v8.1.2
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: Windows 10
• Network issues:
  • Geographic location where npm was run:
  • I use a proxy to connect to the npm registry.
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

(none of the above)

[garrettloy]

Also experiencing this. Simply running npm install repeatedly eventually works for me....

In that screencap, the third 'node install' completed successfully.. no other commands were run.

Have seen .rxjs.DELETE referenced multiple times, other missing .DELETE files are pretty sporadic

[dkent600]

Yes, same here.

[nerdybeast]

Same here

10305 silly finalize C:\projects\simple-vf-cli\node_modules\core-js
10306 verbose unlock done using C:\Users\xxxxxxxxx\AppData\Roaming\npm-cache\_locks\staging-0a8fbe58d39bfe29.lock for C:\projects\simple-vf-cli\node_modules\.staging
10307 verbose stack Error: ENOENT: no such file or directory, rename 'C:\projects\simple-vf-cli\node_modules\core-js' -> 'C:\projects\simple-vf-cli\node_modules\.core-js.DELETE'
10307 verbose stack     at Error (native)
10308 verbose cwd C:\projects\simple-vf-cli
10309 verbose Windows_NT 10.0.10586
10310 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\xxxxxxxxxx\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "install" "pouchdb@latest"
10311 verbose node v6.9.3
10312 verbose npm  v5.0.3
10313 error path C:\projects\simple-vf-cli\node_modules\core-js
10314 error code ENOENT
10315 error errno -4058
10316 error syscall rename
10317 error enoent ENOENT: no such file or directory, rename 'C:\projects\simple-vf-cli\node_modules\core-js' -> 'C:\projects\simple-vf-cli\node_modules\.core-js.DELETE'
10318 error enoent This is related to npm not being able to find a file.
10319 verbose exit [ -4058, true ]

UPDATE:
I tries removing the node_modules folder and the package-lock.json file, still received this error.

[dkent600]

Same thing happens with npm link

[nerdybeast]

Yes, running npm install over and over eventually worked, seems like there is a race condition during the install command with npm5.

[dkent600]

After npm got to the point that it was unusable, just before reinstalling it, I had an idea: I opened task manager (I'm using Windows) and found a bunch of instances of nodejs running. I was able to shut them all down. Then when I ran npm install again, which at this time was failing 100% of the time, and found that it was able to execute without any problem.

I'm going to try to figure out where these other instances of nodejs are coming from. So far it looks like Visual Studio Code and Visual Studio 2017.

[MeirionHughes]

In addition to the .DELETE errors, I'm also getting rename errors - and it freezes for about 20 seconds ( finalise:foo) before issuing an error. example:

npm ERR! path D:\Code\data.server\node_modules\.staging\ts-node-9bd1c32e
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall rename
npm ERR! Error: EPERM: operation not permitted, rename 'D:\Code\data.server\node_modules\.staging\ts-node-9bd1c32e' -> 'D:\Code\data.server\node_modules\ts-node'
npm ERR!  { Error: EPERM: operation not permitted, rename 'D:\Code\data.server\node_modules\.staging\ts-node-9bd1c32e' -> 'D:\Code\data.server\node_modules\ts-node'
npm ERR!   cause:
npm ERR!    { Error: EPERM: operation not permitted, rename 'D:\Code\data.server\node_modules\.staging\ts-node-9bd1c32e' -> 'D:\Code\data.server\node_modules\ts-node'
npm ERR!      errno: -4048,
npm ERR!      code: 'EPERM',
npm ERR!      syscall: 'rename',
npm ERR!      path: 'D:\\Code\\data.server\\node_modules\\.staging\\ts-node-9bd1c32e',
npm ERR!      dest: 'D:\\Code\\data.server\\node_modules\\ts-node' },
npm ERR!   errno: -4048,
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'rename',
npm ERR!   path: 'D:\\Code\\data.server\\node_modules\\.staging\\ts-node-9bd1c32e',
npm ERR!   dest: 'D:\\Code\\data.server\\node_modules\\ts-node'

retrying a few times generally solves either error. I've noticed I'm getting the .DELETE error consistently with something like typescript or ts-node. dedupe race condition?

Edit: I'm afraid this issue has led me to switch to yarn.

Edit: possibly related: microsoft/vscode#29204

[peterbakonyi05]

Had same issue, thanks for @dkent600 for the suggested workaround (closing VS Code). At this point if I had the option to move to yarn, I would. Will do for my own projects...

[nerdybeast]

I've had many similar problems working with Yarn... I would caution with switching to Yarn, they don't handle compiled native C modules very well (for instance LevelDB which cannot be installed globally using Yarn for some reason).

[wfmmurali]

Hey guys ..I am still having the same issue(#8723 referred above) after following here and installing npm few different times . is Switching to Yarn is the only fix ??

a) Installed Npm 4 to 5 times . ran into the same issue
b) tried creating a new user account on my MacBook - nogo went into the same issue

[nerdybeast]

@wfmmurali by "Installed Npm 4 to 5 times" are you meaning you actually installed the npm cli 4 to 5 times or ran the npm install command that many times? I eventually got it to work by running the npm install command several times.

[gust42]

have same problem, it works when i shutdown the Visual Studio Code thats open for that project

[MeirionHughes]

@wfmmurali are you using vscode?

[wfmmurali]

@nerdybeast Yes running the npm install command 4 to 5 times

@MeirionHughes no , not VSCODE. Java with Appium

[dkent600]

@wfmmurali Check to see whether some other application has instances of node running in the background. If so, try to terminate them and then retry your npm command.

[eimerreis]

@dkent600 thanks! That worked for me. Closing my editor and terminating all running node instances made it work

[janpio]

If you are using Visual Studio Code and have this problem, here is an issue about that you can track: microsoft/vscode#28593

[matthiasg]

Closing VS Code did solve the issue for me.

I would guess it might be a case not of a running node instance but of VS Code or similar tools watching the node_modules folder while it is being manipulated which can lead to locking issues.

Optimally npm should retry a few times before giving up or doing less manipulations like delete or rename (cannot delete/rename while a watcher is trying to read stats from the file)

[dkent600]

@matthiasg Two other tools have also been implicated besides Code (Visual Studio itself and another ["Java with Appium", whatever that is]).

Have you ensured that there are no other instances of node running?

[matthiasg]

@dkent600 as I said, closing vs code did solve the issue.

as for other apps also interfering I would assume they might be watching for filesystem changes as well and try to act upon each change right away. at least that would be a theory of mine.

[dkent600]

@matthiasg Oops, sorry, in haste I misread your comment.

[gucong3000]

Same to me.
node 8.1.2
npm 5.0.3
Windows 10.0.15063

E:\work\eclint (npm_dependencies) (eclint@2.2.0)
$ npm i
npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
npm ERR! path E:\work\eclint\node_modules\tslint
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename 'E:\work\eclint\node_modules\tslint' -> 'E:\work\eclint\node_modules\.tslint.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\cdyf\AppData\Roaming\npm-cache\_logs\2017-07-07T02_12_43_678Z-debug.log

E:\work\eclint (npm_dependencies) (eclint@2.2.0)
$ npm i
npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
npm ERR! path E:\work\eclint\node_modules\tslint
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename 'E:\work\eclint\node_modules\tslint' -> 'E:\work\eclint\node_modules\.tslint.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\cdyf\AppData\Roaming\npm-cache\_logs\2017-07-07T02_19_35_740Z-debug.log

[markwhitfeld]

Just as a thought, if there are many tools interfering with the current approach that npm is taking with the .DELETE and .STAGING folders, is there a different approach that won't have the same opportunities for tools to interfere with it?
It actually looks like the issue is occurring here:
lib/install/action/finalize.js - line 52: function moveStagingToDestination...

function moveStagingToDestination () {
  return destinationIsClear()
    .then(actuallyMoveStaging)
    .catch(() => moveOldDestinationAway().then(actuallyMoveStaging))
}

The moveOldDestinationAway() call is throwing the error we see, but there is an underlying error being swallowed up (empty catch) that is being thrown by the actuallyMoveStaging call.

function actuallyMoveStaging () {
  return move(extractedTo, pkg.realpath, moveOpts)
}

I suspect that the staging folder is being locked up by whichever tool is being used and then the move fails. The move is failing in our case because the source file is being locked up. By the action being performed in the catch I suspect that it was originally thought that the destination was getting in the way and needed removing... this is not true in our case.
The approach could be changed to storing the staging folders in a folder that the tools won't touch.
This could be outside of the project folder (and therefore the tool's reach - I think that this could apply to the DELETE, .staging and any other temp folders), or alternatively the 'node_modules/.staging' folder could be ignored explicitly by the tools.

Ignoring the node_modules/.staging folder may be a temporary workaround for this particular issue but I think that npm should adjust the approach to be more resilient to tools.

@zkat or @iarna (or whoever else from the team) what do you think?

[mjbvz]

For VSCode users that see this error while VSCode is running or while there are any lingering Code-Helper processes around: there was a bug in VSCode 1.13 that could cause the reported npm error. Here's an overview of the issue: microsoft/vscode#28593 (comment)

I have taken a fix in to VSCode 1.14 which should come out early next week. You can also try the fix in the current VSCode insiders build: https://code.visualstudio.com/insiders

[micah-williamson]

Closing VS Code worked for me.

[rogierschouten]

but closing all node-related processes isn't really a solution to this issue right? Please let't get this resolved because this is a blocking issue for us and we're still stuck using yarn

[ghost]

For me it was Malwarebytes the whole f*** time i had to uninstall it ,and it did work smoothly lol.

[retorquere]

And another spurious "hey MWB for me too lol". Did you not read the thread @flushedfriendd? we know. Christ.

[kevinhaas]

You should probably close it if you care that much. Seems like you just enjoy bitching at folks, though.

[jakeNiemiec]

@kevinhaas MWB (MalWareBytes) is a symptom to a deeper problem, the larger issue has to do with "no such file or directory" on *nix systems or that the actual error message is much too generic to troubleshoot. I am sure the npm team (more specifically @iarna) is aware of this.

While I am glad your problem was resolved, those of us who are getting this without MWB installed don't appreciate hundreds of "Me too, thanks." showing up in our inboxes.

[ghost]

@retorquere IT'S JUST A COMMENT calm down jesus christ.

[nickmccurdy]

Please lock this thread.

[solinad21]

Hello, thinking badly (related to mwb), could there be the possibility that some dependency of our projects could infiltrate unsafe code or unsafe actions or traces of "something" unsafe? I mention this because at least I try to have a hardaware superior to that of a normal user and that is very much desired, for example, by miners.

Excuse me if this message is not appropriate to the subject.

[scottdear]

If I remove package-lock.json it works for me. I am on *nix, have killed all my node processes and I am not running VSCode. It appears there is some issue with how it uses package-lock.json.

[callenj]

MWB 3.4.5 solves this issue. (or did for me). You can find the discussion and download link here:
https://forums.malwarebytes.com/topic/224958-blocks-npm-from-working/

[chadahahn]

Hi everyone, spent a couple of hours before turning off MalwareBytes Ransomware Protection, and finally got things to work.

[mathieulj]

I have just encountered this very issue. I have no node processes active and I dont even have vscode installed. Removing the package-lock.json solves the issue for me. In my case the errors only seems to occur in the dependencies of a 'file://../other_package' module so maybe it's related to the symlink?

Example:

> git checkout HEAD -- package-lock.json
> npm install
...
ENOENT: no such file or directory, rename '/opt/other_package/node_modules/commander' -> '/opt/other_package/node_modules/.commander.DELETE'
...
> rm package-lock.json
> npm install
...
added 140 packages from 90 contributors in 9.629s

Edit:
Debian Stretch x64, node v8.11.1 & npm 5.8.0

[nicbuitr]

Last night I had this problem again but turning off Windows Defender didn't work as last time, so what I ended up doing was copying the "node_modules" folder from other project to the one I was trying to setup, then "npm install" and it worked.

The downside of this, is that I don't know if "npm install" removes the extra modules that are not required by the new project, therefore having extra module folders that are not being used.

[HikmetTenis]

Im getting ,DELETE issue in Ubuntu 16.04 with npm 3,5,2.. I got no VSCODE, no Malware, no Defender, not sure node-gyp would cause any sharing issue, if I run npm install individually for that package, it works, it is my workaround anyways but I dont like workarounds.

[GCSBOSS]

For me the problem was solved apparently with npm uninstall ... and then npm install ....

[klianlopez]

I was installing using bash in powershell. I tried switching to normal cmd and it works

[kcrwfrd]

Just experienced this on MacOS 10.13.4 with npm 5.6.0, and no other instances of node running. Removing the package-lock.json file got it working.

[linzx1993]

First of all i use private proxy npm。
i have same error in node@8.10.0
but good when i reset node version to @6.11.3

[alexgorbatchev]

Just experienced this issue with npm 6.x. Closing VScode didn’t work for me. I had to delete package-lock.json file, then everything started working as expected.

[miensol]

Same problem here. Removing package-lock.json makes the problem go away. However, this is by no means a solution nor a workaround.

[itsmepetrov]

Same here

[Hychhayrith]

Hello everyone, for this problem just run npm update after that you can install module as usual

[zkat]

This looks like it's pretty much resolved for most folks.

To be clear: If you're experiencing this:

1. Make sure you have the latest npm (npm install -g npm).
2. Add an exception to your antivirus to ignore the node_modules folder in your project.
3. $ rm -rf node_modules package-lock.json
4. $ npm install

And you should be back in business.

I'm going to both close and lock this, since it's resolved. If you're still experiencing this and you have a reliable repro, and none of the above steps fixed it for you please file a new issue in the npm.community forum with any necessary repro steps so that we can look into it, in case there's still a missing bit. Cheers!