This repository has been archived by the owner. It is now read-only.

Intermittent EPERM issues when renaming Windows files during install #12059

Closed
adriaanthomas opened this Issue Mar 25, 2016 · 98 comments

Comments

Projects
None yet
@adriaanthomas

adriaanthomas commented Mar 25, 2016

On npm@2.14.20:

2016-03-25T00:12:37.6515576Z npm ERR! Windows_NT 6.3.9600
2016-03-25T00:12:37.6515576Z npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install"
2016-03-25T00:12:37.6515576Z npm ERR! node v4.4.0
2016-03-25T00:12:37.6515576Z npm ERR! npm  v2.14.20
2016-03-25T00:12:37.6515576Z npm ERR! path D:\npm-cache\mkdirp\0.5.1\package.tgz.1638249806
2016-03-25T00:12:37.6515576Z npm ERR! code EPERM
2016-03-25T00:12:37.6515576Z npm ERR! errno -4048
2016-03-25T00:12:37.6515576Z npm ERR! syscall rename
2016-03-25T00:12:37.6515576Z npm ERR! Error: EPERM: operation not permitted, rename 'D:\npm-cache\mkdirp\0.5.1\package.tgz.1638249806' -> 'D:\npm-cache\mkdirp\0.5.1\package.tgz'
2016-03-25T00:12:37.6515576Z npm ERR!     at Error (native)
2016-03-25T00:12:37.6515576Z npm ERR!  { [Error: EPERM: operation not permitted, rename 'D:\npm-cache\mkdirp\0.5.1\package.tgz.1638249806' -> 'D:\npm-cache\mkdirp\0.5.1\package.tgz']
2016-03-25T00:12:37.6515576Z npm ERR!   errno: -4048,
2016-03-25T00:12:37.6515576Z npm ERR!   code: 'EPERM',
2016-03-25T00:12:37.6515576Z npm ERR!   syscall: 'rename',
2016-03-25T00:12:37.6515576Z npm ERR!   path: 'D:\\npm-cache\\mkdirp\\0.5.1\\package.tgz.1638249806',
2016-03-25T00:12:37.6515576Z npm ERR!   dest: 'D:\\npm-cache\\mkdirp\\0.5.1\\package.tgz',
2016-03-25T00:12:37.6515576Z npm ERR!   parent: 'ssb2b' }
2016-03-25T00:12:37.6671853Z npm ERR! 
2016-03-25T00:12:37.6671853Z npm ERR! Please try running this command again as root/Administrator.
2016-03-25T00:12:37.6671853Z npm ERR! Please include the following file with any support request:
2016-03-25T00:12:37.6671853Z npm ERR!     D:\work\4\s\npm-debug.log

npm-debug.log is here. This was an npm install --force with an empty cache directory (as the debug log shows), but clearly that did not help this time.

Clearing the cache sometimes helps, but just as often it will fail again on some package (not always the same one).

@zkat zkat changed the title from npm install fails on Windows with EPERM error on renaming package.tgz file in cache to Intermittent EPERM issues when renaming Windows files during install Mar 25, 2016

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Mar 25, 2016

Member

We've seen errors like this intermittently, and I don't know the immediate cause. I'm going to mark this as a bug on windows so we can be sure to check it out in time. Thanks for the report! I'll try and redirect other people with similar problems over here.

Member

zkat commented Mar 25, 2016

We've seen errors like this intermittently, and I don't know the immediate cause. I'm going to mark this as a bug on windows so we can be sure to check it out in time. Thanks for the report! I'll try and redirect other people with similar problems over here.

@adriaanthomas

This comment has been minimized.

Show comment
Hide comment
@adriaanthomas

adriaanthomas Apr 5, 2016

Perhaps linked to npm/write-file-atomic#10?

The rename operation does actually complete (the temporary file is no longer there). Manually removing the package directory from cache and running npm install again is how we (eventually) work around this now.

adriaanthomas commented Apr 5, 2016

Perhaps linked to npm/write-file-atomic#10?

The rename operation does actually complete (the temporary file is no longer there). Manually removing the package directory from cache and running npm install again is how we (eventually) work around this now.

@adriaanthomas

This comment has been minimized.

Show comment
Hide comment
@adriaanthomas

adriaanthomas Apr 5, 2016

As this was becoming quite a pain, I looked in to this a bit further. I ended up making some changes to npm/node_modules/graceful-fs/polyfills.js (commented out a block and added different code, which waits for 100 ms before retrying):

  // on Windows, A/V software can lock the directory, causing this
  // to fail with an EACCES or EPERM if the directory contains newly
  // created files.  Try again on failure, for up to 1 second.
  if (process.platform === "win32") {
    fs.rename = (function (fs$rename) { return function (from, to, cb) {
      var start = Date.now()
      fs$rename(from, to, function CB (er) {
        /*if (er
            && (er.code === "EACCES" || er.code === "EPERM")
            && Date.now() - start < 1000) {
          return fs$rename(from, to, CB)
        }*/
        if (er && (er.code === "EACCES" || er.code === "EPERM")) {
          var timeDelta = Date.now() - start
          if (timeDelta <= 1000) {
            setTimeout(() => {
              console.log(`Retrying after ${timeDelta} + 100 (${Date.now() - start}) ms: ${from} -> ${to}`);
              fs$rename(from, to, CB)
            }, 100)
            return
          } else {
            console.log(`GIVING UP after ${timeDelta} ms: ${from} -> ${to} (${er.code})`);
          }
        }
        if (cb) cb(er)
      })
    }})(fs.rename)
  }

Without the call to setTimout renames seem to just continue racing against each other, until the 1 second deadline has passed.

While I don't know what ultimately is causing this, the above patch seems to work -- for now at least. Finding the exact values (interval + deadline) is obviously tricky and system dependant, but we'll run with these settings for a while and I'll report back if we come across this issue again.

Maybe it's worth suggesting something like this (without the ugly debug logging) upstream?

adriaanthomas commented Apr 5, 2016

As this was becoming quite a pain, I looked in to this a bit further. I ended up making some changes to npm/node_modules/graceful-fs/polyfills.js (commented out a block and added different code, which waits for 100 ms before retrying):

  // on Windows, A/V software can lock the directory, causing this
  // to fail with an EACCES or EPERM if the directory contains newly
  // created files.  Try again on failure, for up to 1 second.
  if (process.platform === "win32") {
    fs.rename = (function (fs$rename) { return function (from, to, cb) {
      var start = Date.now()
      fs$rename(from, to, function CB (er) {
        /*if (er
            && (er.code === "EACCES" || er.code === "EPERM")
            && Date.now() - start < 1000) {
          return fs$rename(from, to, CB)
        }*/
        if (er && (er.code === "EACCES" || er.code === "EPERM")) {
          var timeDelta = Date.now() - start
          if (timeDelta <= 1000) {
            setTimeout(() => {
              console.log(`Retrying after ${timeDelta} + 100 (${Date.now() - start}) ms: ${from} -> ${to}`);
              fs$rename(from, to, CB)
            }, 100)
            return
          } else {
            console.log(`GIVING UP after ${timeDelta} ms: ${from} -> ${to} (${er.code})`);
          }
        }
        if (cb) cb(er)
      })
    }})(fs.rename)
  }

Without the call to setTimout renames seem to just continue racing against each other, until the 1 second deadline has passed.

While I don't know what ultimately is causing this, the above patch seems to work -- for now at least. Finding the exact values (interval + deadline) is obviously tricky and system dependant, but we'll run with these settings for a while and I'll report back if we come across this issue again.

Maybe it's worth suggesting something like this (without the ugly debug logging) upstream?

@adriaanthomas

This comment has been minimized.

Show comment
Hide comment
@adriaanthomas

adriaanthomas Apr 5, 2016

I apologise for all the noise, but this does not work either.

Maybe if it's OK to ignore errors in renaming package.json in the cache (#9696), would it be OK to ignore errors here too?

adriaanthomas commented Apr 5, 2016

I apologise for all the noise, but this does not work either.

Maybe if it's OK to ignore errors in renaming package.json in the cache (#9696), would it be OK to ignore errors here too?

adriaanthomas pushed a commit to adriaanthomas/npm that referenced this issue Apr 7, 2016

Adriaan Thomas
fix: ignore EPERM errors on Windows on package install in cache
Currently logging as warning, can probably be downgraded. Fixes #12059.
@adriaanthomas

This comment has been minimized.

Show comment
Hide comment
@adriaanthomas

adriaanthomas Apr 7, 2016

FWIW we're now running with the patch mentioned above and no longer suffer from this issue.

adriaanthomas commented Apr 7, 2016

FWIW we're now running with the patch mentioned above and no longer suffer from this issue.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Apr 11, 2016

Member

Great! Could you make a PR out of if so we can review it? :)

Member

zkat commented Apr 11, 2016

Great! Could you make a PR out of if so we can review it? :)

@markerikson

This comment has been minimized.

Show comment
Hide comment
@markerikson

markerikson Apr 13, 2016

I had been trying to install some CLI packages off NPM the last couple days, and they were failing every time. Hand-copying the polyfills.js edit and the add-local-tarballs.js edit into my current NPM install seems to have mostly resolved that, although I had to bump the timeout in polyfills.js up to 10000ms.

For reference, I have been seeing this behavior under my normal user account, and the same thing happened when explicitly running a command prompt as Administrator. I am in an environment that includes a number of antivirus and security tools running, so that seems to fit the list of causes.

As a related note, the error messages I had been seeing look like it was trying to rename the "final" folder to the "temporary delete folder", which seems backwards to me. Sample:

npm ERR! Error: EPERM: operation not permitted, rename 'C:\Users\USERNAME\AppData\Roaming\npm\node_modules\npm-check' -> 'C:\Users\USERNAME\AppData\Roaming\npm\node_modules\.npm-check.DELETE'
npm ERR!     at moveAway (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\npm\lib\install\action\finalize.js:38:5)
npm ERR!     at destStatted (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\npm\lib\install\action\finalize.js:27:7)
npm ERR!     at FSReqWrap.oncomplete (fs.js:82:15)

markerikson commented Apr 13, 2016

I had been trying to install some CLI packages off NPM the last couple days, and they were failing every time. Hand-copying the polyfills.js edit and the add-local-tarballs.js edit into my current NPM install seems to have mostly resolved that, although I had to bump the timeout in polyfills.js up to 10000ms.

For reference, I have been seeing this behavior under my normal user account, and the same thing happened when explicitly running a command prompt as Administrator. I am in an environment that includes a number of antivirus and security tools running, so that seems to fit the list of causes.

As a related note, the error messages I had been seeing look like it was trying to rename the "final" folder to the "temporary delete folder", which seems backwards to me. Sample:

npm ERR! Error: EPERM: operation not permitted, rename 'C:\Users\USERNAME\AppData\Roaming\npm\node_modules\npm-check' -> 'C:\Users\USERNAME\AppData\Roaming\npm\node_modules\.npm-check.DELETE'
npm ERR!     at moveAway (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\npm\lib\install\action\finalize.js:38:5)
npm ERR!     at destStatted (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\npm\lib\install\action\finalize.js:27:7)
npm ERR!     at FSReqWrap.oncomplete (fs.js:82:15)
@joffrey-bion

This comment has been minimized.

Show comment
Hide comment
@joffrey-bion

joffrey-bion May 3, 2016

Any plan in merging this PR?

We have been having this problem for months now, and it looks like the issue could be solved at least temporarily.

joffrey-bion commented May 3, 2016

Any plan in merging this PR?

We have been having this problem for months now, and it looks like the issue could be solved at least temporarily.

@RefactorMan

This comment has been minimized.

Show comment
Hide comment
@RefactorMan

RefactorMan May 23, 2016

I have similar issue. Can't npm install.

EPERM - 4048
Operation not permitted, rename....

Clean cache doesn't work. Every installation, the rename error comes from other package. ALWAYS from NPM-CACHE path!

  • - force doesn't work either..

RefactorMan commented May 23, 2016

I have similar issue. Can't npm install.

EPERM - 4048
Operation not permitted, rename....

Clean cache doesn't work. Every installation, the rename error comes from other package. ALWAYS from NPM-CACHE path!

  • - force doesn't work either..
@apomelov

This comment has been minimized.

Show comment
Hide comment
@apomelov

apomelov Jun 3, 2016

@adriaanthomas , tried you PR with my local nodejs but error is still here. I'm not familiar with nodejs and even js, but the project contains both java and js and I need to build it. I faced the problem when tried to build several projects with same dependencies concurrently (about ten projects). I've applied the changeset to /nodejs/node_modules/npm/lib/cache/add-local-tarball.js. Maybe I've done something wrong?

apomelov commented Jun 3, 2016

@adriaanthomas , tried you PR with my local nodejs but error is still here. I'm not familiar with nodejs and even js, but the project contains both java and js and I need to build it. I faced the problem when tried to build several projects with same dependencies concurrently (about ten projects). I've applied the changeset to /nodejs/node_modules/npm/lib/cache/add-local-tarball.js. Maybe I've done something wrong?

@thejones

This comment has been minimized.

Show comment
Hide comment
@thejones

thejones Jul 12, 2016

To add to what @markerikson pointed out I get the same error when installing modules on Windows 7, using a proxy, and on a very locked down (slow) computer and network. Different packages but the error is always in the moveAway function of finalize.js

I suspect this is anti-virus or encryption related and the happy path is not allowed. I have seen similar issues fixed by waiting or trying again so I tried forcing this call to wait and everything is successful.

Fails:

  function moveAway () {
    rename(pkg.path, delpath, whenOldMovedAway)
  }

Works:

  function moveAway () {
    setTimeout(()=>{
      rename(pkg.path, delpath, whenOldMovedAway)
    }, 1000);
  }

Portion of log file https://gist.github.com/thejones/b4e91935789110c5838cea922db46040

I am running this through the Node console as an Administrator.
NPM Version: 3.9.3
Node Version: 6.2.1

thejones commented Jul 12, 2016

To add to what @markerikson pointed out I get the same error when installing modules on Windows 7, using a proxy, and on a very locked down (slow) computer and network. Different packages but the error is always in the moveAway function of finalize.js

I suspect this is anti-virus or encryption related and the happy path is not allowed. I have seen similar issues fixed by waiting or trying again so I tried forcing this call to wait and everything is successful.

Fails:

  function moveAway () {
    rename(pkg.path, delpath, whenOldMovedAway)
  }

Works:

  function moveAway () {
    setTimeout(()=>{
      rename(pkg.path, delpath, whenOldMovedAway)
    }, 1000);
  }

Portion of log file https://gist.github.com/thejones/b4e91935789110c5838cea922db46040

I am running this through the Node console as an Administrator.
NPM Version: 3.9.3
Node Version: 6.2.1

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jul 20, 2016

@zkat I've a company where most of their machines do this repeatedly, any ideas on a fix? Anything we can do to help figure the bug out? The hacks like disabling antivirus, etc., haven't helped.

sam-github commented Jul 20, 2016

@zkat I've a company where most of their machines do this repeatedly, any ideas on a fix? Anything we can do to help figure the bug out? The hacks like disabling antivirus, etc., haven't helped.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 1, 2016

I am still facing the same issue for finalize.js , tried with the code change above mentioned still having the same problem.. is there any solution for this. can anyone please guide me what to do with this error ?

ghost commented Sep 1, 2016

I am still facing the same issue for finalize.js , tried with the code change above mentioned still having the same problem.. is there any solution for this. can anyone please guide me what to do with this error ?

@wvankuipers

This comment has been minimized.

Show comment
Hide comment
@wvankuipers

wvankuipers Sep 5, 2016

This is not an issue with NPM itself but with one of it's (core) dependencies fs-write-stream-atomic, I created a PR that should fix this issue some time ago but it is still pending.

wvankuipers commented Sep 5, 2016

This is not an issue with NPM itself but with one of it's (core) dependencies fs-write-stream-atomic, I created a PR that should fix this issue some time ago but it is still pending.

@aldenchan

This comment has been minimized.

Show comment
Hide comment
@aldenchan

aldenchan Sep 15, 2016

We ran into similar issue installing apiconnect due to A/V. The workstation has McAfee and Parity bit9 installed.

We saw the problem not during the cache rename but later in the install.

npm ERR! Error: EPERM: operation not permitted, rename 'C:\ibmapiconnect\npm\no
e_modules\apiconnect\node_modules\strong-cluster-control' -> 'C:\ibmapiconnect
pm\node_modules\apiconnect\node_modules.strong-cluster-control.DELETE'
npm ERR!     at moveAway (C:\ibmapiconnect\npm\node_modules\npm\lib\install\act
on\finalize.js:38:5)
npm ERR!     at destStatted (C:\ibmapiconnect\npm\node_modules\npm\lib\install
ction\finalize.js:27:7)
npm ERR!     at FSReqWrap.oncomplete (fs.js:82:15)
npm ERR!

We tried the fs-write-stream-atomic PR fix but that doesn't resolve the problem. Able to install apiconnect by making the pollyfills.js change but has to increase the timeout to over 500000ms.

aldenchan commented Sep 15, 2016

We ran into similar issue installing apiconnect due to A/V. The workstation has McAfee and Parity bit9 installed.

We saw the problem not during the cache rename but later in the install.

npm ERR! Error: EPERM: operation not permitted, rename 'C:\ibmapiconnect\npm\no
e_modules\apiconnect\node_modules\strong-cluster-control' -> 'C:\ibmapiconnect
pm\node_modules\apiconnect\node_modules.strong-cluster-control.DELETE'
npm ERR!     at moveAway (C:\ibmapiconnect\npm\node_modules\npm\lib\install\act
on\finalize.js:38:5)
npm ERR!     at destStatted (C:\ibmapiconnect\npm\node_modules\npm\lib\install
ction\finalize.js:27:7)
npm ERR!     at FSReqWrap.oncomplete (fs.js:82:15)
npm ERR!

We tried the fs-write-stream-atomic PR fix but that doesn't resolve the problem. Able to install apiconnect by making the pollyfills.js change but has to increase the timeout to over 500000ms.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Sep 23, 2016

Any npm response on above comment? Anything we can do to help get this fixed? We had an entire customer site where every single one of their devs (using their corporate Windows images) was incapable of installing apiconnect, and what @aldenchan described fixed this for across the whole site.

sam-github commented Sep 23, 2016

Any npm response on above comment? Anything we can do to help get this fixed? We had an entire customer site where every single one of their devs (using their corporate Windows images) was incapable of installing apiconnect, and what @aldenchan described fixed this for across the whole site.

@wvankuipers

This comment has been minimized.

Show comment
Hide comment
@wvankuipers

wvankuipers Sep 25, 2016

@aldenchan

We tried the fs-write-stream-atomic PR fix but that doesn't resolve the problem. Able to install apiconnect by making the pollyfills.js change but has to increase the timeout to over 500000ms.

As the error you described is not related to the NPM build process itself (moving a file from a temp location to its definit location during installation) it is not related to the fs-write-stream-atomic PR.

The issue you described can also be a issue within the package itself.

wvankuipers commented Sep 25, 2016

@aldenchan

We tried the fs-write-stream-atomic PR fix but that doesn't resolve the problem. Able to install apiconnect by making the pollyfills.js change but has to increase the timeout to over 500000ms.

As the error you described is not related to the NPM build process itself (moving a file from a temp location to its definit location during installation) it is not related to the fs-write-stream-atomic PR.

The issue you described can also be a issue within the package itself.

@Meligy

This comment has been minimized.

Show comment
Hide comment
@Meligy

Meligy Oct 4, 2016

As mentioned here, the workaround by @thejones in seems to work.

Tested installing angular-cli with Node 4.4.2, NPM 3.10, on Windows 8.1 with admin access and McAfee antivirus we cannot disable.

Meligy commented Oct 4, 2016

As mentioned here, the workaround by @thejones in seems to work.

Tested installing angular-cli with Node 4.4.2, NPM 3.10, on Windows 8.1 with admin access and McAfee antivirus we cannot disable.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Oct 21, 2016

We (IBM and specifically @aldenchan) have an entire customer site where none of the corporate Windows machines can install apiconnect with npm.

Their A/V software (McAfee and Parity bit9) appears to lock new files for up to a minute.

The fix by @adriaanthomas in #12059 (comment) worked for us, I reworked it into a PR: isaacs/node-graceful-fs#97

I think the fix mentioned above in #12059 (comment) would work, too, but it's delay would have to be much longer, or it would have to poll until success. It basically shows that polling can occur in graceful-fs, where everyone can take advantage of it, or in moveAway(). I'm not sure where that latter code is, I assume its in npm somewhere. I've no opinion on where the poll/timeout has to be, but it has to be somewhere.

Any chance of getting one of the fixes merged, @ceejbot or someone? We are floating the graceful-fs hack on site right now :-(

sam-github commented Oct 21, 2016

We (IBM and specifically @aldenchan) have an entire customer site where none of the corporate Windows machines can install apiconnect with npm.

Their A/V software (McAfee and Parity bit9) appears to lock new files for up to a minute.

The fix by @adriaanthomas in #12059 (comment) worked for us, I reworked it into a PR: isaacs/node-graceful-fs#97

I think the fix mentioned above in #12059 (comment) would work, too, but it's delay would have to be much longer, or it would have to poll until success. It basically shows that polling can occur in graceful-fs, where everyone can take advantage of it, or in moveAway(). I'm not sure where that latter code is, I assume its in npm somewhere. I've no opinion on where the poll/timeout has to be, but it has to be somewhere.

Any chance of getting one of the fixes merged, @ceejbot or someone? We are floating the graceful-fs hack on site right now :-(

othiym23 added a commit that referenced this issue Nov 3, 2016

graceful-fs@4.1.10
Better backoff for EPERM on Windows.

Credit: @sam-github
Fixes: #12059
Reviewed-By: @othiym23
Reviewed-By: @isaacs
PR-URL: isaacs/node-graceful-fs#97

othiym23 added a commit that referenced this issue Nov 4, 2016

graceful-fs@4.1.10
Better backoff for EPERM on Windows.

Credit: @sam-github
Fixes: #12059
Reviewed-By: @othiym23
Reviewed-By: @isaacs
PR-URL: isaacs/node-graceful-fs#97
@mateodelnorte

This comment has been minimized.

Show comment
Hide comment
@mateodelnorte

mateodelnorte Dec 2, 2016

Chiming in to note I'm still seeing this behavior with npm@4.0.5: #15124 (comment)

mateodelnorte commented Dec 2, 2016

Chiming in to note I'm still seeing this behavior with npm@4.0.5: #15124 (comment)

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Dec 5, 2016

Member

We're getting enough of these again that I'm going to reopen this. I'm really not sure how much we'll be able to do about this -- graceful-fs already has a minute-long backoff for this. The other possibility is that the A\V software is changing permissions or ownership for the file itself, and I'm not sure there's anything at all we can do about that except improve the error message a bit.

Member

zkat commented Dec 5, 2016

We're getting enough of these again that I'm going to reopen this. I'm really not sure how much we'll be able to do about this -- graceful-fs already has a minute-long backoff for this. The other possibility is that the A\V software is changing permissions or ownership for the file itself, and I'm not sure there's anything at all we can do about that except improve the error message a bit.

@zkat zkat reopened this Dec 5, 2016

@NodeGuy

This comment has been minimized.

Show comment
Hide comment
@NodeGuy

NodeGuy Dec 9, 2016

This problem just went away for me when I upgraded from Node.js v4 to v6.

NodeGuy commented Dec 9, 2016

This problem just went away for me when I upgraded from Node.js v4 to v6.

@legodude17

This comment has been minimized.

Show comment
Hide comment
@legodude17

legodude17 Dec 9, 2016

Contributor

Anyone still having this issue on Node v6 and npm@4?

Contributor

legodude17 commented Dec 9, 2016

Anyone still having this issue on Node v6 and npm@4?

@NodeGuy

This comment has been minimized.

Show comment
Hide comment
@NodeGuy

NodeGuy Dec 9, 2016

Oops, I spoke to soon. It just came back for me with Node 6.9.2 and npm 4.0.3.

NodeGuy commented Dec 9, 2016

Oops, I spoke to soon. It just came back for me with Node 6.9.2 and npm 4.0.3.

@JCMais

This comment has been minimized.

Show comment
Hide comment
@JCMais

JCMais Apr 10, 2017

I can confirm that stopping Windows Search service made the error go away.

JCMais commented Apr 10, 2017

I can confirm that stopping Windows Search service made the error go away.

@SteveBrumbaugh

This comment has been minimized.

Show comment
Hide comment
@SteveBrumbaugh

SteveBrumbaugh Apr 11, 2017

I was successful enabling the Windows 10 local Administrator account, logging on with it and using NetBeans (right-click on the quickstart project and select 'npm install' from the context menu). I don't think NetBeans was the difference because I had been unsuccessful using it with my regular user account, which is in the Administrator's group. My attempts had all failed referencing renaming of .staging selenium-webdriver folder. Many have written about intermittent failures, but I had consistent failures in dozens of attempts over the course of a week.

SteveBrumbaugh commented Apr 11, 2017

I was successful enabling the Windows 10 local Administrator account, logging on with it and using NetBeans (right-click on the quickstart project and select 'npm install' from the context menu). I don't think NetBeans was the difference because I had been unsuccessful using it with my regular user account, which is in the Administrator's group. My attempts had all failed referencing renaming of .staging selenium-webdriver folder. Many have written about intermittent failures, but I had consistent failures in dozens of attempts over the course of a week.

@18steps

This comment has been minimized.

Show comment
Hide comment
@18steps

18steps Apr 11, 2017

I have the same problems with installs. With yarn for sure, but presumably with npm as well.

For me it turns out to be the anti-virus.

My problem is I am on a company computer and so cannot turn off the anti-virus. I was able to use task manager to shut them down for a bit, and in those few moments get the installations to go through. However, the antivirus processes keep regenerating, and when I got to what I believe is "the root" one, it told me there was a critical security issue and that the computer would be shut down in a minute and to save my files, and sure enough it did.

I believe the issue is that when a file is generated, the antivirus detects it, and for some moments have the file open to scan. This is presumably when the rename is attempted and blocked.

I think if installations could be written such that they

  • attempt the rename, and

  • if it fails, reattempt in some hundred milliseconds (possibly longer depending on the size of the file?), up to some limited number of times, this issue would be solved.

18steps commented Apr 11, 2017

I have the same problems with installs. With yarn for sure, but presumably with npm as well.

For me it turns out to be the anti-virus.

My problem is I am on a company computer and so cannot turn off the anti-virus. I was able to use task manager to shut them down for a bit, and in those few moments get the installations to go through. However, the antivirus processes keep regenerating, and when I got to what I believe is "the root" one, it told me there was a critical security issue and that the computer would be shut down in a minute and to save my files, and sure enough it did.

I believe the issue is that when a file is generated, the antivirus detects it, and for some moments have the file open to scan. This is presumably when the rename is attempted and blocked.

I think if installations could be written such that they

  • attempt the rename, and

  • if it fails, reattempt in some hundred milliseconds (possibly longer depending on the size of the file?), up to some limited number of times, this issue would be solved.

@SteveBrumbaugh

This comment has been minimized.

Show comment
Hide comment
@SteveBrumbaugh

SteveBrumbaugh Apr 11, 2017

SteveBrumbaugh commented Apr 11, 2017

@18steps

This comment has been minimized.

Show comment
Hide comment
@18steps

18steps Apr 11, 2017

18steps commented Apr 11, 2017

@SteveBrumbaugh

This comment has been minimized.

Show comment
Hide comment
@SteveBrumbaugh

SteveBrumbaugh Apr 11, 2017

SteveBrumbaugh commented Apr 11, 2017

@chrisjpatty

This comment has been minimized.

Show comment
Hide comment
@chrisjpatty

chrisjpatty Apr 24, 2017

Contributor

Ok, so I kept getting this exact same issue and none of the above solutions worked for me, including running as an administrator, clearing the NPM cache, stopping background services, etc. I finally realized that I had been running Webpack (through create-react-app) in the background, and it was interfering with my installs somehow. Presumably because it was trying to recompile halfway through the install. Anyways, as soon as I stopped that process my install worked perfectly. Hope this helps someone!

Contributor

chrisjpatty commented Apr 24, 2017

Ok, so I kept getting this exact same issue and none of the above solutions worked for me, including running as an administrator, clearing the NPM cache, stopping background services, etc. I finally realized that I had been running Webpack (through create-react-app) in the background, and it was interfering with my installs somehow. Presumably because it was trying to recompile halfway through the install. Anyways, as soon as I stopped that process my install worked perfectly. Hope this helps someone!

ransombriggs added a commit to heroku/cli-engine that referenced this issue Apr 27, 2017

@about-code

This comment has been minimized.

Show comment
Hide comment
@about-code

about-code Apr 28, 2017

I recently ran into the rename EPERM-issues when installing packages of mine on a windows machine. I could reproduce it with npm install for package versions which I deployed together with an npm-shrinkwrap.json. Versions without that file installed without the permission issues. Can anyone confirm this behavior?

I'm on node v6.9.5 and npm 3.10.10

about-code commented Apr 28, 2017

I recently ran into the rename EPERM-issues when installing packages of mine on a windows machine. I could reproduce it with npm install for package versions which I deployed together with an npm-shrinkwrap.json. Versions without that file installed without the permission issues. Can anyone confirm this behavior?

I'm on node v6.9.5 and npm 3.10.10

@legodude17

This comment has been minimized.

Show comment
Hide comment
@legodude17

legodude17 Apr 28, 2017

Contributor

Please go through the troubleshooting guide.

Contributor

legodude17 commented Apr 28, 2017

Please go through the troubleshooting guide.

@npm-robot

This comment has been minimized.

Show comment
Hide comment
@npm-robot

npm-robot Jun 19, 2017

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.

npm-robot commented Jun 19, 2017

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jun 19, 2017

This is a bug, re-confirmed by multiple independent npm users, it should be marked as a bug, and fixed!

sam-github commented Jun 19, 2017

This is a bug, re-confirmed by multiple independent npm users, it should be marked as a bug, and fixed!

@18steps

This comment has been minimized.

Show comment
Hide comment
@18steps

18steps Jun 19, 2017

The issue has various causes, but all of them (?) are because the file is in use by some other program and thus cannot be renamed. To fix it, the operation should be retried after some timeout up to some number of times, or one could copy the file and delete the original file (worse solution as it requires more space).

18steps commented Jun 19, 2017

The issue has various causes, but all of them (?) are because the file is in use by some other program and thus cannot be renamed. To fix it, the operation should be retried after some timeout up to some number of times, or one could copy the file and delete the original file (worse solution as it requires more space).

@Nogostradamus

This comment has been minimized.

Show comment
Hide comment
@Nogostradamus

Nogostradamus Jun 19, 2017

I have to say that my problem has been solved by itself for some reason. Now I can update and install with no problems and I couldn't before. I don't remember changing anything though.

Nogostradamus commented Jun 19, 2017

I have to say that my problem has been solved by itself for some reason. Now I can update and install with no problems and I couldn't before. I don't remember changing anything though.

@lukedubber

This comment has been minimized.

Show comment
Hide comment
@lukedubber

lukedubber Jun 20, 2017

I was having the same issue, tried all the suggestions on this page and still was having the issue.
What worked for me was stopping Visual Studio Code and making sure no node processes where running.

Hope this helps!

FYI: Running Windows 10 Pro. (Windows_NT 10.0.14393)
npm v3.10.10
node v6.11.0

lukedubber commented Jun 20, 2017

I was having the same issue, tried all the suggestions on this page and still was having the issue.
What worked for me was stopping Visual Studio Code and making sure no node processes where running.

Hope this helps!

FYI: Running Windows 10 Pro. (Windows_NT 10.0.14393)
npm v3.10.10
node v6.11.0

@chrisjpatty

This comment has been minimized.

Show comment
Hide comment
@chrisjpatty

chrisjpatty Jun 20, 2017

Contributor

It sounds like this is an issue for which a universal solution isn't feasible, but what would be helpful would be a more detailed and accurate error message. It took quite a bit of googling to find this thread. Perhaps something like the following:

"This operation was rejected by your operating system. It's possible that the file was already in use. To resolve, try running this action again as an administrator and make sure that that the file isn't being used by another program"

This would make this problem a little more comprehensible to the lay user.

Contributor

chrisjpatty commented Jun 20, 2017

It sounds like this is an issue for which a universal solution isn't feasible, but what would be helpful would be a more detailed and accurate error message. It took quite a bit of googling to find this thread. Perhaps something like the following:

"This operation was rejected by your operating system. It's possible that the file was already in use. To resolve, try running this action again as an administrator and make sure that that the file isn't being used by another program"

This would make this problem a little more comprehensible to the lay user.

@18steps

This comment has been minimized.

Show comment
Hide comment
@18steps

18steps Jun 20, 2017

@chrisjpatty Universally I don't see why this would work: To fix it, the operation should be retried after some timeout up to some number of times, or one could copy the file and delete the original file (worse solution as it requires more space).
On the systems where this issue doesn't occur, the extra code would not be run, and where it does occur it seems a likely fix.

18steps commented Jun 20, 2017

@chrisjpatty Universally I don't see why this would work: To fix it, the operation should be retried after some timeout up to some number of times, or one could copy the file and delete the original file (worse solution as it requires more space).
On the systems where this issue doesn't occur, the extra code would not be run, and where it does occur it seems a likely fix.

@chrisjpatty

This comment has been minimized.

Show comment
Hide comment
@chrisjpatty

chrisjpatty Jun 20, 2017

Contributor

@18steps I think that's a possible solution, but it also sounds like, from the various comments in this thread, that the problem doesn't have a clear origin. Having a timeout could become laborious if there's a long series of files to process, but could work. But even if that is implemented, a better error message for when it still times out would be helpful to the user.

Contributor

chrisjpatty commented Jun 20, 2017

@18steps I think that's a possible solution, but it also sounds like, from the various comments in this thread, that the problem doesn't have a clear origin. Having a timeout could become laborious if there's a long series of files to process, but could work. But even if that is implemented, a better error message for when it still times out would be helpful to the user.

@mLaird

This comment has been minimized.

Show comment
Hide comment
@mLaird

mLaird Jun 23, 2017

mLaird commented Jun 23, 2017

@ClickSimply

This comment has been minimized.

Show comment
Hide comment
@ClickSimply

ClickSimply Jul 4, 2017

I can confirm this issue seemed to go away on my Windows 10 machine after I closed my Visual Studio Code IDE that had the project folder open. Running NPM 5.0.3 and Node 8.0.0

ClickSimply commented Jul 4, 2017

I can confirm this issue seemed to go away on my Windows 10 machine after I closed my Visual Studio Code IDE that had the project folder open. Running NPM 5.0.3 and Node 8.0.0

@varunezhava

This comment has been minimized.

Show comment
Hide comment
@varunezhava

varunezhava Aug 10, 2017

I managed to find the source causing this issue. It was one of my vbscript(cscript.exe) which was running in background on my system causing the issue.
Once i killed it, the installation went through smoothly.
@lukedubber : Your inputs helped to find the cause. Thanks

varunezhava commented Aug 10, 2017

I managed to find the source causing this issue. It was one of my vbscript(cscript.exe) which was running in background on my system causing the issue.
Once i killed it, the installation went through smoothly.
@lukedubber : Your inputs helped to find the cause. Thanks

@Coruscate5

This comment has been minimized.

Show comment
Hide comment
@Coruscate5

Coruscate5 Aug 10, 2017

@chrisjpatty I'd like to second a retry timeout of sorts - I've run into this issue every time I need to npm install, and every time it's been resolved by just "trying again" enough times, which suggests that a small retry window might fix the majority of occurrences

Coruscate5 commented Aug 10, 2017

@chrisjpatty I'd like to second a retry timeout of sorts - I've run into this issue every time I need to npm install, and every time it's been resolved by just "trying again" enough times, which suggests that a small retry window might fix the majority of occurrences

@kboyd31

This comment has been minimized.

Show comment
Hide comment
@kboyd31

kboyd31 Aug 17, 2017

I was just discussing this issue with my team, I'd like to third the @Coruscate5 and @chrisjpatty suggestion, this problem seems to fail randomly on files when a simple "try it again a few times" or "wait and try again" option would solve it. We can get this to work here about 10% of the time, the rest of the time it fails. None of the suggested fixes worked for any of our team.

kboyd31 commented Aug 17, 2017

I was just discussing this issue with my team, I'd like to third the @Coruscate5 and @chrisjpatty suggestion, this problem seems to fail randomly on files when a simple "try it again a few times" or "wait and try again" option would solve it. We can get this to work here about 10% of the time, the rest of the time it fails. None of the suggested fixes worked for any of our team.

@dogboydog

This comment has been minimized.

Show comment
Hide comment
@dogboydog

dogboydog Aug 18, 2017

I already commented about this on my reopen of this issue, but just for visibility in case anyone at npm looks into this, at my workplace people encounter this every day. I have literally had to create a bash loop of "npm install -g" and let it run and walk away once to get a package to successfully install. Regardless of whether npm is directly causing the error or not, I hope you can make the install process a little more robust and recover from the cause so that we don't have to spend so much time explaining to users that we can't control the issue, being unable to test due to the issue, etc.

dogboydog commented Aug 18, 2017

I already commented about this on my reopen of this issue, but just for visibility in case anyone at npm looks into this, at my workplace people encounter this every day. I have literally had to create a bash loop of "npm install -g" and let it run and walk away once to get a package to successfully install. Regardless of whether npm is directly causing the error or not, I hope you can make the install process a little more robust and recover from the cause so that we don't have to spend so much time explaining to users that we can't control the issue, being unable to test due to the issue, etc.

@Coruscate5

This comment has been minimized.

Show comment
Hide comment
@Coruscate5

Coruscate5 Sep 14, 2017

BTW - since was still a major issue for me, I spent some time in ProcMon trying to figure out what could be locking files.

2 things seemed to be consistently "looking" at the thousands of files being modified by a simple package install - SearchIndexer.exe (Windows Search), and a different seemingly unrelated Node process.

After temporarily disabling the Windows Search service & stopping it, I realized the rogue "other" Node process was the one running automatically in Visual Studio 2017. It appears that VS' node version is constantly looking for changes in the project if the solution is open.

Thus there were 2 fixes: Closing Visual Studio & killing Windows Search while running NPM installs, or probably more correct, simply running the NPM installs directly from inside Visual Studio by updating the package.json file. (dependencies are restored automatically by VS 2017, and subsequently Node, when package.json is changed)

Coruscate5 commented Sep 14, 2017

BTW - since was still a major issue for me, I spent some time in ProcMon trying to figure out what could be locking files.

2 things seemed to be consistently "looking" at the thousands of files being modified by a simple package install - SearchIndexer.exe (Windows Search), and a different seemingly unrelated Node process.

After temporarily disabling the Windows Search service & stopping it, I realized the rogue "other" Node process was the one running automatically in Visual Studio 2017. It appears that VS' node version is constantly looking for changes in the project if the solution is open.

Thus there were 2 fixes: Closing Visual Studio & killing Windows Search while running NPM installs, or probably more correct, simply running the NPM installs directly from inside Visual Studio by updating the package.json file. (dependencies are restored automatically by VS 2017, and subsequently Node, when package.json is changed)

@cornillemichiel

This comment has been minimized.

Show comment
Hide comment
@cornillemichiel

cornillemichiel Jan 25, 2018

Still happens.

On premise VSTS Agent - Windows server 2012 R2
node v9.4.0
npm v5.6.0

29440 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install"
29441 verbose node v9.4.0
29442 verbose npm  v5.6.0
29443 error path e:\Build\agents\scully\_work\26\s\src\Our.Project.Name\node_modules\requirejs\bin\r.js.3238022762
29444 error code EPERM
29445 error errno -4048
29446 error syscall rename
29447 error Error: EPERM: operation not permitted, rename  'e:\Build\agents\scully\_work\26\s\src\Our.Project.Name\node_modules\requirejs\bin\r.js.3238022762' -> 'e:\Build\agents\scully\_work\26\s\src\Our.Project.Name\node_modules\requirejs\bin\r.js'

cornillemichiel commented Jan 25, 2018

Still happens.

On premise VSTS Agent - Windows server 2012 R2
node v9.4.0
npm v5.6.0

29440 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install"
29441 verbose node v9.4.0
29442 verbose npm  v5.6.0
29443 error path e:\Build\agents\scully\_work\26\s\src\Our.Project.Name\node_modules\requirejs\bin\r.js.3238022762
29444 error code EPERM
29445 error errno -4048
29446 error syscall rename
29447 error Error: EPERM: operation not permitted, rename  'e:\Build\agents\scully\_work\26\s\src\Our.Project.Name\node_modules\requirejs\bin\r.js.3238022762' -> 'e:\Build\agents\scully\_work\26\s\src\Our.Project.Name\node_modules\requirejs\bin\r.js'

@thomasjo thomasjo referenced this issue Apr 9, 2018

Closed

Cannot publish new package from windows #780

1 of 1 task complete
@evil-shrike

This comment has been minimized.

Show comment
Hide comment
@evil-shrike

evil-shrike May 14, 2018

I'm also experiencing the issue while installing requirejs on Windows Server 2008R2.
npm 5.5.1
node 9.2.0

[19:43:17][npm install] npm ERR! path C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058
[19:43:17][npm install] npm ERR! code EPERM
[19:43:17][npm install] npm ERR! errno -4048
[19:43:17][npm install] npm ERR! syscall rename
[19:43:17][npm install] npm ERR! Error: EPERM: operation not permitted, rename 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058' -> 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js'
[19:43:17][npm install] npm ERR!  { Error: EPERM: operation not permitted, rename 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058' -> 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js'
[19:43:17][npm install] npm ERR!   cause: 
[19:43:17][npm install] npm ERR!    { Error: EPERM: operation not permitted, rename 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058' -> 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js'
[19:43:17][npm install] npm ERR!      errno: -4048,
[19:43:17][npm install] npm ERR!      code: 'EPERM',
[19:43:17][npm install] npm ERR!      syscall: 'rename',
[19:43:17][npm install] npm ERR!      path: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js.1177017058',
[19:43:17][npm install] npm ERR!      dest: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js' },
[19:43:17][npm install] npm ERR!   stack: 'Error: EPERM: operation not permitted, rename \'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js.1177017058\' -> \'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js\'',
[19:43:17][npm install] npm ERR!   errno: -4048,
[19:43:17][npm install] npm ERR!   code: 'EPERM',
[19:43:17][npm install] npm ERR!   syscall: 'rename',
[19:43:17][npm install] npm ERR!   path: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js.1177017058',
[19:43:17][npm install] npm ERR!   dest: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js',
[19:43:17][npm install] npm ERR!   parent: 'mypackage' }
[19:43:17][npm install] npm ERR! 
[19:43:17][npm install] npm ERR! Please try running this command again as root/Administrator.
[19:43:17][npm install] 
[19:43:17][npm install] npm ERR! A complete log of this run can be found in:
[19:43:17][npm install] npm ERR!     C:\Users\BuildUser\AppData\Roaming\npm-cache\_logs\2018-05-14T16_43_17_435Z-debug.log

no VS instances is running, it's my build server. there's no Windows Search there either (it's basically Win7)

evil-shrike commented May 14, 2018

I'm also experiencing the issue while installing requirejs on Windows Server 2008R2.
npm 5.5.1
node 9.2.0

[19:43:17][npm install] npm ERR! path C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058
[19:43:17][npm install] npm ERR! code EPERM
[19:43:17][npm install] npm ERR! errno -4048
[19:43:17][npm install] npm ERR! syscall rename
[19:43:17][npm install] npm ERR! Error: EPERM: operation not permitted, rename 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058' -> 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js'
[19:43:17][npm install] npm ERR!  { Error: EPERM: operation not permitted, rename 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058' -> 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js'
[19:43:17][npm install] npm ERR!   cause: 
[19:43:17][npm install] npm ERR!    { Error: EPERM: operation not permitted, rename 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js.1177017058' -> 'C:\TeamCity\buildAgent\work\b84c51626ef4d7cf\node_modules\requirejs\bin\r.js'
[19:43:17][npm install] npm ERR!      errno: -4048,
[19:43:17][npm install] npm ERR!      code: 'EPERM',
[19:43:17][npm install] npm ERR!      syscall: 'rename',
[19:43:17][npm install] npm ERR!      path: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js.1177017058',
[19:43:17][npm install] npm ERR!      dest: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js' },
[19:43:17][npm install] npm ERR!   stack: 'Error: EPERM: operation not permitted, rename \'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js.1177017058\' -> \'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js\'',
[19:43:17][npm install] npm ERR!   errno: -4048,
[19:43:17][npm install] npm ERR!   code: 'EPERM',
[19:43:17][npm install] npm ERR!   syscall: 'rename',
[19:43:17][npm install] npm ERR!   path: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js.1177017058',
[19:43:17][npm install] npm ERR!   dest: 'C:\\TeamCity\\buildAgent\\work\\b84c51626ef4d7cf\\node_modules\\requirejs\\bin\\r.js',
[19:43:17][npm install] npm ERR!   parent: 'mypackage' }
[19:43:17][npm install] npm ERR! 
[19:43:17][npm install] npm ERR! Please try running this command again as root/Administrator.
[19:43:17][npm install] 
[19:43:17][npm install] npm ERR! A complete log of this run can be found in:
[19:43:17][npm install] npm ERR!     C:\Users\BuildUser\AppData\Roaming\npm-cache\_logs\2018-05-14T16_43_17_435Z-debug.log

no VS instances is running, it's my build server. there's no Windows Search there either (it's basically Win7)

@legodude17

This comment has been minimized.

Show comment
Hide comment
@legodude17

legodude17 May 14, 2018

Contributor

@evil-shrike do you have an antivirus running?

Contributor

legodude17 commented May 14, 2018

@evil-shrike do you have an antivirus running?

@evil-shrike

This comment has been minimized.

Show comment
Hide comment
@evil-shrike

evil-shrike May 14, 2018

@legodude17 no, that 2008r2 even has no Windows Defender.

evil-shrike commented May 14, 2018

@legodude17 no, that 2008r2 even has no Windows Defender.

@legodude17

This comment has been minimized.

Show comment
Hide comment
@legodude17

legodude17 May 14, 2018

Contributor

Can you try updating to the latest version of npm?

Contributor

legodude17 commented May 14, 2018

Can you try updating to the latest version of npm?

@evil-shrike

This comment has been minimized.

Show comment
Hide comment
@evil-shrike

evil-shrike May 16, 2018

@legodude17 I've updated to 6.0x latest and it seems the problem has gone, thanks

evil-shrike commented May 16, 2018

@legodude17 I've updated to 6.0x latest and it seems the problem has gone, thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.