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

Yarn should normalize permissions when untarring packages. #961

Closed
mcbryant opened this issue Oct 13, 2016 · 13 comments · Fixed by #2826
Closed

Yarn should normalize permissions when untarring packages. #961

mcbryant opened this issue Oct 13, 2016 · 13 comments · Fixed by #2826
Labels

Comments

@mcbryant
Copy link

Do you want to request a feature or report a bug?
This is a bug report.

What is the current behavior?
Yarn keeps the permissions of the archives is untars intact, while npm normalizes them. This means some npm packages cannot be installed using yarn.

If the current behavior is a bug, please provide the steps to reproduce.
Create a folder with the following package.json:

{
  "name": "test-case",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "@types/history": "2.0.38"
  }
}

Run yarn using a version of yarn with support for scoped modules (e.g., master).

Note: This is not an issue with scoped modules in general. Other scoped modules work on master.

What is the expected behavior?
The operation should succeed (as it does with npm install), and the the permissions should be as follows:

total 40
-rw-r--r--   1 mcbr   611B Oct  3 08:23 README.md
-rw-r--r--   1 mcbr   5.7K Oct  3 08:23 index.d.ts
drwxr-xr-x  11 mcbr   374B Oct 12 22:07 lib
-rw-r--r--   1 mcbr   2.1K Oct 12 22:07 package.json
-rw-r--r--   1 mcbr   1.1K Oct  3 08:23 types-metadata.json

./node_modules/@types/history/lib:
total 72
-rw-r--r--  1 mcbr   624B Oct  3 08:23 DOMUtils.d.ts
-rw-r--r--  1 mcbr   143B Oct  3 08:23 actions.d.ts
-rw-r--r--  1 mcbr   133B Oct  3 08:23 createBrowserHistory.d.ts
-rw-r--r--  1 mcbr   130B Oct  3 08:23 createHashHistory.d.ts
-rw-r--r--  1 mcbr   203B Oct  3 08:23 createLocation.d.ts
-rw-r--r--  1 mcbr   134B Oct  3 08:23 createMemoryHistory.d.ts
-rw-r--r--  1 mcbr   135B Oct  3 08:23 useBasename.d.ts
-rw-r--r--  1 mcbr   182B Oct  3 08:23 useBeforeUnload.d.ts
-rw-r--r--  1 mcbr   165B Oct  3 08:23 useQueries.d.ts

I don't think it's required that the date for "lib" be set to the current date. npm install just does this for some reason.

Instead, the operation does not succeed:

yarn install v0.15.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error https://registry.npmjs.org/@types/history/-/history-2.0.38.tgz: EACCES: permission denied, open '/Users/mcbr/.yarn-cache/npm-@types/history-2.0.38/lib/DOMUtils.d.ts'
    at Error (native)
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Note: untarring https://registry.npmjs.org/@types/history/-/history-2.0.38.tgz results in:

total 40
-rw-r--r--   1 mcbr   611B Oct  3 08:23 README.md
-rw-r--r--   1 mcbr   5.7K Oct  3 08:23 index.d.ts
drw-r--r--  11 mcbr   374B Oct  3 08:23 lib
-rw-r--r--   1 mcbr   603B Oct  3 08:23 package.json
-rw-r--r--   1 mcbr   1.1K Oct  3 08:23 types-metadata.json

./history/lib:

Note that lib does not have executable ("cd") permissions. While we could ask DefinitelyTyped (@types/history) to fix their permissions, I'm reporting the issue here in case you with to improve compatibility with npm packages, especially in case there are other strange packages.

Please mention your node.js, yarn and operating system version.

  • Node v6.6.0
  • Yarn ee07644ed9080a22ca9742c9383100b8f03221a3 (master)
  • macOS Sierra
@IRus
Copy link

IRus commented Oct 13, 2016

Same error for me:

error https://registry.npmjs.org/@types/react-router/-/react-router-2.0.37.tgz: EACCES: permission denied, open '/home/yoda/.yarn-cache/npm-@types/react-router-2.0.37/lib/History.d.ts'
    at Error (native)
  • Node v6.7.0
  • Ubuntu 16.04.1 LTS
  • 0.15.0

@donaldpipowitch
Copy link
Contributor

FYI: Bug is still reproducible on yarn@0.16.0 (on macOS 10.12).

{
  "name": "foo",
  "version": "1.0.0",
  "private": true
}
$ yarn add @types/react-router@2.0.37
yarn add v0.16.0
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error An unexpected error occured, please open a bug report with the information provided in "/Users/name/Workspace/test/foo/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Arguments:
  /Users/name/.nvm/versions/node/v6.7.0/bin/node /Users/name/.nvm/versions/node/v6.7.0/bin/yarn add @types/react-router@2.0.37

PATH:
  /usr/local/sbin:/Users/name/.nvm/versions/node/v6.7.0/bin:/Users/name/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin

Yarn version:
  0.16.0

Node version:
  6.7.0

Platform:
  darwin x64

npm manifest:
  {
    "name": "foo",
    "version": "1.0.0",
    "private": true
  }

yarn manifest:
  No manifest

bower manifest:
  No manifest

Lockfile:
  No lockfile

Trace:
  Error: https://registry.yarnpkg.com/@types/react-router/-/react-router-2.0.37.tgz: EACCES: permission denied, open '/Users/name/.yarn-cache/npm-@types/react-router-2.0.37/lib/History.d.ts'
      at Error (native)

@gtirloni
Copy link

Reproduced on:

  • Fedora 25
  • node 6.9.1
  • yarn 0.17.8

@jacalata
Copy link

I ran into this today with yarn 0.18
D:\dev>yarn add istanbul
yarn add v0.18.1
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
error An unexpected error occurred: "EPERM: operation not permitted, open 'D:\dev\node_modules\abbrev\LICENSE'".
info If you think this is a bug, please open a bug report with the information provided in "D:\dev\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

@gnesher
Copy link

gnesher commented Feb 13, 2017

Seeing the same problem, only windows machines. Yarn v0.19.1 on Windows 10 package is RXJS 5.0.3

@owendismuke
Copy link

owendismuke commented Feb 28, 2017

I just ran into this as well on yarn v0.21.3. The interesting this is that yarn install worked twice, but the third time -> on, it started kicking this error everytime. package.json didn't change between the calls.

Edit: After playing with the cache a bit, I notice that something still has control of the package
that it kicks this error on. i.e. It won't let me delete the directory in cache/.tmp/.../package_that_kicked_the_error

@Zacorich
Copy link

For everyone experiencing same problem on Windows please try running yarn commands with Administrator rights. By default all terminals launched on Windows are not administrative.

@owendismuke
Copy link

@Zacorich That may be a temporary workaround, but should not be considered a solution.

@silvanaacc
Copy link

I tried opening the Windows command line with Administrator rights, but I got a similar error:

An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\Users\...\\Local\Yarn\cache\...\.yarn-tarball.tgz'

@mr-White
Copy link

Same error on Windows when running with Administrator rights.

I'm here from the advanced angular seed project.

My issue seems to first be with the node-sass package.

There's also this weird thing I've noticed with npm start, and killing the process. Sometimes it leaves a task running node in the background (see background processes for Windows Task Manager). In doing so, it locks files which may be related. On Windows, I often have to kill those node processes before running them again. Might switch to Linux soon (been trying Windows out for a few weeks, after taking a hiatus from Mac)

My error message:

yarn install v0.21.3
[1/4] Resolving packages...
warning electron-prebuilt@1.4.13: electron-prebuilt has been renamed to electron. For more details, see http://electron.atom.io/blog/2016/08/16/npm-install-electron
warning gulp-atom-electron > github-releases > minimatch@0.2.12: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning gulp-atom-electron > github-releases > grunt > minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning gulp-atom-electron > github-releases > request > node-uuid@1.4.8: Use uuid module instead
warning electron-prebuilt > electron-download > nugget > progress-stream > through2 > xtend > object-keys@0.4.0:
[2/4] Fetching packages...
warning fsevents@1.0.17: The platform "win32" is incompatible with this module.
info "fsevents@1.0.17" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
error An unexpected error occurred: "EPERM: operation not permitted, unlink 'T:\\Work\\Projects\\YouFeelin\\node_modules\\node-sass\\vendor\\win32-x64-48\\binding.node'".
info If you think this is a bug, please open a bug report with the information provided in "T:\\Work\\Projects\\YouFeelin\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

@bestander
Copy link
Member

This should be fixed in 0.23.x

@yangxiaolin
Copy link

version 0.24.5 still has this problem on MacOS 10.12.6

@Vaccano
Copy link

Vaccano commented Jan 18, 2018

I am still seeing this issue. I was on 0.23. To be sure, I updated to 1.3.2 and I still see it.

It is happening on my auto build server. (So it is a fresh install when there is nothing in the node_modules folder.)

Here is the output:

D:\bld\ce657248929e20e7\shipment-tracking>yarn install
yarn install v1.3.2
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.1.1: The platform "win32" is incompatible with this module.
info "fsevents@1.1.1" is an optional dependency and failed compatibility check.
Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
error An unexpected error occurred: "EPERM: operation not permitted, open 'D:\bld\ce657248929e20e7\shipment-tracking\yarn.lock'".
info If you think this is a bug, please open a bug report with the information p
rovided in "D:\bld\ce657248929e20e7\shipment-tracking\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this
command.

I opened the error log and this was what was at the end (after success for a bunch of other packages).

yargs@~3.10.0:
version "3.10.0"
resolved "https://registry.yarnpkg.com/yargs/-/yargs-3.10.0.tgz#f7ee7bd857dd7c1d2d38c0e74efbd681d1431fd1"
dependencies:
camelcase "^1.0.2"
cliui "^2.1.0"
decamelize "^1.0.0"
window-size "0.1.0"

Trace:
Error: EPERM: operation not permitted, open 'D:\bld\ce657248929e20e7\shipment-tracking\yarn.lock'
at Error (native)

If I remove the read-only flag on my yarn.lock file then it works fine.... Not sure why it needs to update the lock file after a fresh install...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.