Repository navigation
fs: too strict range check on 'mode' parameter #20498
Description
Activity
Seeing the same issue here. Breaking
graceful-fsactually breaksvinyl-fs, so it actually breaksgulp(yes, evengulp@4).In my case, I only see the issue when running on CI...
Reacted by Timothée Rebours, Charles Samborski, Moritz Mazetti, Francisco Puig and Sp90cc @targos @BridgeAR We discussed about unifying this check in #19973 (review) I am leaning towards masking off the relevant bits since that's what the underlying POSIX API usually does.
I'm good with masking off the bits and relaxing the check :)
Also, it's obvious we don't have good test coverage for this particular case so it would be good to expand that a bit.
Reacted by Richard LauReacted by Nick OliverI also agree that masking off seems the right thing to do.
Hi,
I just wanted to mention that I also encountered this bug. It happens when I use Gulp (graceful-fs) on Gitlab CI:RangeError [ERR_OUT_OF_RANGE]: The value of "mode" is out of range. Received 33206 at Object.fs.fchmod (fs.js:1024:11) at Object.fchmod (/builds/demurgos/node-devkit/node_modules/graceful-fs/polyfills.js:237:17) at mode (/builds/demurgos/node-devkit/node_modules/vinyl-fs/lib/file-operations.js:237:10) at onStat (/builds/demurgos/node-devkit/node_modules/vinyl-fs/lib/file-operations.js:227:14) at /builds/demurgos/node-devkit/node_modules/graceful-fs/polyfills.js:287:18 at FSReqWrap.oncomplete (fs.js:150:5)Reacted by Eric M. Dantas, Benjamin Rancourt, Geoffrey Booth, atropo and Sp90I'm having the same issue above with Gulp 4(graceful-fs) in my local build. What can I do to fix this?
Reacted by Eric M. Dantas, Denys Séguret, atropo and Sp90same here.
Reacted by Eric M. Dantasgraceful-fs's RangeError [ERR_OUT_OF_RANGE] solved by #20588.
Great work. Thanks!52 remaining items
When it will be in master? 10.4.1 released but still
RangeError [ERR_OUT_OF_RANGE]: The value of "mode" is out of range. Received 33206
at Object.fs.fchmod (fs.js:1058:11)@delagen It's on v10.x-staging now, should be available in the next release.
@joyeecheung This was broken for about 7 releases of 10.x branch. Speed of fixes make me sad (
Reacted by Denys SéguretReacted by Ruben Bridgewater and Yves-Marie K. RinquinComments like yours make me sad. It adds nothing except another notification email to 100+ people.
Reacted by Ruben Bridgewater, Ron Waldon-Howe, Yves-Marie K. Rinquin, Siddartha Adusumalli, Aaron Sherwood, Ahmad Awais, Ken Rogers and Nick OliverReacted by Denys Séguret and Violet- added a commit that references this issue
on Jun 20, 2018 - added a commit that references this issue
on Jul 27, 2026
Since version 10, function like
fs.chmod()orfs.mkdir()check if theirmodeparameter is belowo777throwing a RangeError exception if the condition isn't satisfied.This requirement is too strict as the mode parameter can often be above
o777if it need to set theS_ISUIDorS_ISGIDbits.Furthermore this range check break several node packages (e.g.
graceful-fsused by over 1400 other packages) in a very common scenario:A program wants to create a new file/directory with the same rights that a reference file/directory. Often the
modeattribute offs.Statsobject is directly passed tofs.chmod()orfs.mkdir(). However thefs.Stats.modeis always aboveo777(e.g.o100644) since it also contains the file type bits.Classic POSIX version of
chmodormkdirseems to handle those kind a values without complaining by discarding the irrelevant bits instead of throwing an error. Why do Node need to be so brutal about it?