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

chmodrKid(Sync) fails with EACCES when the target is readonly #19

Open
mbargiel opened this issue Oct 18, 2018 · 0 comments
Open

chmodrKid(Sync) fails with EACCES when the target is readonly #19

mbargiel opened this issue Oct 18, 2018 · 0 comments

Comments

@mbargiel
Copy link

mbargiel commented Oct 18, 2018

OS: MacOS High Sierra 10.13.6
Node version: 8.11.3
chmodr version: 1.2.0

I'm using chmodr to make sure all readonly files in a directory are recursively set to be writable. This used to work with 1.0.2 but it fails 1.2.0. I tracked down the failure to this point (which seems to be the fs core module itself):

  fs.lchmodSync = function(path, mode) {
    const fd = fs.openSync(path, constants.O_WRONLY | constants.O_SYMLINK); // <---- This - can't open a file with constants.O_WRONLY if it's not already writable

    // Prefer to return the chmod error, if one occurs,
    // but still try to close, and report closing errors if they occur.
    let ret;
    try {
      ret = fs.fchmodSync(fd, mode);
    } finally {
      fs.closeSync(fd);
    }
    return ret;
  };

If I understand correctly, fs.lchmod seems to assume the target is a symlink, which are always writable (for the owner) and executable (for everyone), on MacOS anyway, according to a check I just did. Therefore the code should check whether the file is a symlink before choosing between chmod and lchmod.

@mbargiel mbargiel changed the title lchmodSync fails with EACCES when the target is readonly chmodrKid(Sync) fails with EACCES when the target is readonly Oct 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant