I get the following error while running the lint task anywhere under C:\Program Files (x86)
Error: EPERM, operation not permitted 'C:\Documents and Settings'
at Object.fs.readdirSync (fs.js:500:18)
at exports.glob.recurse (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\node_modules\glob-whatev\lib\glob.js:60:8)
at exports.glob.recurse (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\node_modules\glob-whatev\lib\glob.js:75:11)
at Array.forEach (native)
at exports.glob.recurse (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\node_modules\glob-whatev\lib\glob.js:60:29)
at Object.exports.glob (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\node_modules\glob-whatev\lib\glob.js:87:5)
at file.expand (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\lib\grunt\file.js:58:22)
at Array.map (native)
at Function._.map (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\node_modules\underscore\underscore.js:100:56)
at wrapper.(anonymous function) [as map] (C:\Users\Justin\AppData\Roaming\npm\node_modules\grunt\node_modules\underscore\underscore.js:957:26)
I created a small gruntfile which only lints itself (gist) as a test case. If I place this in C:\Program Files (x86), or any subdirectory, I get the above error when grunting it. If I move the same gruntfile anywhere outside C:\Program Files (x86) it works as expected.
I had the 32 bit version of node installed at one point but have since upgraded (many reboots ago). There is no reference to the 32 bit version of node in my system path variable, anywhere in my registry that I could find, and indeed there is no longer a nodejs folder in the x86 program files directory.
It may also be worth noting that I can execute fs.readdirSync( dir in x86 program files ) outside of grunt without any issues.
I've looked through issues #380, #372, and also joyent/node/issues/3902 which all seemed to have similar symptoms but couldn't find anything that helped.
Have you actually tried this in both the x86 and x64 versions of Node.js?
Yep. I tried re-installing the x86 version (just now, again) and saw the same behavior. Currently back on the x64 version and can confirm it happens in both.
I ran into this while setting up jenkins locally, and it ended up being due to either special characters or spaces the folder name - moving jenkins to a folder that lacked any of those fixed the problem, so at least that's something to look at.
FWIW, it was the default folder in C:\Program Files (x86), so it's likely either the space or ( ) that was causing this.
Yeah, I was suspicious of the space at first but had tested a number of paths outside C:\Program Files (x86) with special chars and spaces (i.e. C:\Program Files\foo (bar) and ) and had not seen any issues there.
C:\Program Files (x86)
C:\Program Files\foo (bar)
But... I tried a few others just now -
Oddly enough I get the same error in these locations:
But not in these:
It appears to not like parenthesis in direct sub folders of C:\?
Closing this for housekeeping reasons. Please re-open it if the issue is still a problem.
FWIW I moved my project files out of C:\Program Files (x86) as a workaround but just now I tried grunting again within that directory and didn't have any issues!
Since I could last reproduce the problem I've upgraded my OS (win7 pro --> win7 ultimate), upgraded grunt (~0.3 --> ~0.4) and upgraded node itself at least once or twice (currently 0.8.16 win 64bit)... Sadly I can't point decisively to one thing though I believe my coworker experienced the same problem with win7 ultimate - he's still using grunt@~0.3 but is on vacation at the moment so i'll need to wait for the new year to check in with him.
I just saw this exact problem on my build server, Windows 2008R2, node 0.8.18, grunt 0.3.17.
The issue is still there with grunt 0.4.0a on Windows 7 with the latest version of node.js. Inside of "C:\Program Files (x86)", nothing works, outside it's ok.
Just throwing this in here: isn't this about the folder in question's read/write permissions?
@barneycarroll No, it's about having certain characters in the top level folder name if I recall correctly.
@dcherman Interesting. I had exactly the same symptoms, but this was outside of C:\Program Files (x86)\ — mine was nested within my user's documents folder. No spaces or parens there… I just assumed somebody had modified permissions relating in some way to Window's User Account Control policy, which then got lost in Windows permission limbo when they went upstream.
C:\Program Files (x86)\