mandelbug EPERM on Windows, possibly related to scoped packages

[Mithgol]

I'm opening this issue because:

• npm is crashing.
• [?] npm is producing an incorrect install.
• npm is doing something I don't understand.

What's going wrong?

npm finishes with an error such as the following:

gyp ERR! node -v v6.11.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm ERR! path U:\Fido\!Node\fidomail2ipfs\node_modules\@types
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall rmdir
npm ERR! Error: EPERM: operation not permitted, rmdir 'U:\Fido\!Node\fidomail2ipfs\node_modules\@types'
npm ERR!     at Error (native)
npm ERR!  { Error: EPERM: operation not permitted, rmdir 'U:\Fido\!Node\fidomail2ipfs\node_modules\@types'
npm ERR!     at Error (native)
npm ERR!   errno: -4048,
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'rmdir',
npm ERR!   path: 'U:\\Fido\\!Node\\fidomail2ipfs\\node_modules\\@types' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

(Despite npm's suspicions, it's indeed running as Administrator.)

It obviously tries to erase the subdirectory @types inside the directory node_modules and fails.

I do not fully understand why npm attempts that.

I suspect that it happens because the fidomail2ipfs package indirectly depends on the scoped packages (with the names such as @types/mkdirp or @types/node) and their names' first part (@types) somehow becomes treated as a subdirectory's name.

I have found that the aforementioned indirect dependency is the following:

• fidomail2ipfs depends on ipfs-api@~14.0.0,

• ipfs-api@~14.0.0 depends on peer-id@~0.8.7, which depends on libp2p-crypto@~0.8.7, which depends on libp2p-crypto-secp256k1@^0.1.4, which depends on libp2p-crypto@~0.8.4, which depends on node-webcrypto-ossl@^1.0.21,

• ipfs-api@~14.0.0 depends on peer-id@~0.8.7, which depends on libp2p-crypto@~0.8.7, which depends on node-webcrypto-ossl@^1.0.21,

• ipfs-api@~14.0.0 depends on peer-info@~0.9.2, which depends on peer-id@^0.8.6, which depends on libp2p-crypto@~0.8.7, which depends on libp2p-crypto-secp256k1@^0.1.4, which depends on libp2p-crypto@~0.8.4, which depends on node-webcrypto-ossl@^1.0.21,

• ipfs-api@~14.0.0 depends on peer-info@~0.9.2, which depends on peer-id@^0.8.6, which depends on libp2p-crypto@~0.8.7, which depends on node-webcrypto-ossl@^1.0.21,

• all of the four aforementioned paths end on node-webcrypto-ossl@^1.0.21, which directly depends on @types/mkdirp@^0.3.29 and @types/node@^6.0.78 and additionally depends on webcrypto-core@^0.1.16 which depends on @types/node@^6.

The same problem does not seem to appear when I install other packages that don't depend on scoped packages.

How can the CLI team reproduce the problem?

Use Windows 7 Professional Service Pack 1 64-bit. (Probably the problem happens on any other 64-bit Windows, but I do not have a variety of them in my avail to check it.)

Grab the packed source code of the fidomail2ipfs package, unpack, run npm install --production in the subdirectory where package.json resides.

Do not expect the problem to manifest reliably. It seems to be a mandelbug that do not appear every time. The problem seem to occur more often on my flash drive than on my hard drive. (Might be a symptom of a race condition affected by longer access times on flash drives.)

Nine examples of generated npm-debug.log files are attached here. These are results of nine successive errors. I deleted node_modules between errors to attempt a clean retry.

supporting information:

• npm -v prints: 5.0.4
• node -v prints: v6.11.0
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: Windows
• 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)..

[Mithgol]

As I have already mentioned, the problem occurs more often on flash drives (thumb drives) and seems to be triggered by their lower speed.

Therefore one of the possible workarounds is to copy a package.json to an empty directory on a much faster drive (an SSD, for example), and run npm install --production there, and move the resulting node_modules to a thumb drive where the original package.json resided.

(I've tried it. It works.)

While the problem seems to be triggered by a lower speed of a thumb drive, that's still a mere guesswork. The real reason still can reside in any other difference (for example, the thumb drive's FAT filesystem compared to my SSD's NTFS).