Node: Error: EPERM: operation not permitted, open 'C:\Users\username\.node_repl_history'

[t0lkman]

On Windows 7 for node 5.5.0 if ".node_repl_history" has hidden attribute, node fails to open.

[Fishrock123]

@t0lkman as an intermediate fix, set the env variable: NODE_REPL_HISTORY=" "

[reidrankin]

As a workaround, you can put .node_repl_history in a folder, set the folder hidden, create a symlink (with mklink) called .node_repl_history to the real file in the hidden folder, and then use attrib /l +h to set the hidden attribute on the symlink but not the file itself. This is stupid, but at least it declutters my user folder.

[Fishrock123]

Maybe we should just continue if there is an error and warn in the repl?

[reidrankin]

The problem is that the error should not occur. Just because the file is set hidden should not cause a permissions error.

[thefourtheye]

@t0lkman Few of us don't use. So can you please show the actual error stack trace or explain in detail what exactly happens?

Edit: nvm. I see the title now.

[be5invis]

And I see this: http://stackoverflow.com/questions/2246990/how-do-i-write-to-a-hidden-file
So maybe when saving repl history, Node should temporary unhide it, save, and re-hide it.

[cjihrig]

I think printing a warning is the best bet. If the user has been fiddling with the file, maybe they don't want Node writing to it. Or, maybe they hadn't realized, and printing a warning will help them fix it.

[t0lkman]

@cjihrig I don't agree with you, I always hide all unnecessary system files on Windows, hidden files shouldn't be considered "read only" hence I don't need any warnings

[reidrankin]

The file is supposed to be hidden. On POSIX systems, the file name starting
with a dot is the marker for a hidden file, so it should be hidden by
default. If a user didn't want it to be writable, they would have set the
read-only bit--which is right next to the checkbox for the hidden bit.

On Mon, Mar 14, 2016 at 6:11 PM Colin Ihrig [email protected]
wrote:

I think printing a warning is the best bet. If the user has been fiddling
with the file, maybe they don't want Node writing to it. Or, maybe they
hadn't realized, and printing a warning will help them fix it.

—
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5261#issuecomment-196542703.

[Fishrock123]

cc @nodejs/platform-windows is there some special way we should attempt to open files that might be hidden on windows?

[reidrankin]

No, that's the problem: I don't know of any other program that has issues
opening hidden files on Windows, excepting the dos-era copy/move/del
commands on the command line, and those are designed that way for
compatibility reasons.
On Tue, Mar 15, 2016 at 4:43 PM Jeremiah Senkpiel [email protected]
wrote:

cc @nodejs/platform-windows
https://github.com/orgs/nodejs/teams/platform-windows is there some
special way we should attempt to open files that might be hidden on windows?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5261#issuecomment-197011666

[seishun]

Node.js does have checks for file availability and fails gracefully if, for example, the file is set to read-only. However, for some reason it opens and closes the file three times - first as 'a+', then as 'r', then as 'w'.

The problem is the third one, where there aren't any checks anymore. Trying to open a hidden file in 'w' mode is an error in Node.js, in Python (great explanation there), in C's fopen (at least using CRT) and I assume in many other languages too.

I can think of the following solutions:

• Use a different mode instead of 'w', maybe 'r+'
• Fix libuv to automatically pass the FILE_ATTRIBUTE_HIDDEN flag if needed (would make it inconsistent with other languages)
• Open the file only once and fail gracefully if it's hidden
• Add failure checks to all three open calls

[joeyespo]

This also happens on Windows 10 with node v6.2.1.

[joeyespo]

Another workaround is to set the NODE_REPL_HISTORY ENV variable to another location. This is what I've been doing.

[wagnlinzh]

add code in the file .node_repl_history and try ?

exit
1+1

[ackvf]

Still an issue, even with other files

fs.js:549
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: EPERM: operation not permitted, open 'C:\Users\Qwerty\.babel.json'
    at Error (native)
    at Object.fs.openSync (fs.js:549:18)
    at Object.fs.writeFileSync (fs.js:1156:15)
    at save (C:\repos\b2bportal-widgets\node_modules\babel-core\lib\api\register\cache.js:35:19)
    at nextTickCallbackWith0Args (node.js:420:9)
    at process._tickCallback (node.js:349:13)
    at Function.Module.runMain (module.js:443:11)
    at startup (node.js:139:18)
    at node.js:968:3

[ccoenen]

Still an issue, Windows 10 64 bit with node v7.4.0:

C:\somewhere\> node
> bootstrap_node.js:148
              throw err;
              ^

Error: EPERM: operation not permitted, open 'C:\Users\<username>\.node_repl_history

[ccoenen]

Why is this marked as "discuss"? There's not really anything to discuss. I know _no_ other tool with this behaviour? It is clearly simply a bug.

[joyeecheung]

From https://github.com/nodejs/node/issues/5261#issuecomment-197251914 and https://github.com/nodejs/node/pull/7005 I think this is a bug. The fix should be in the repl module. https://github.com/nodejs/node/pull/7005 provides a potential fix but it looks stalled for CI failure. I think if someone using Windows has a fix (or can fix it by trying https://github.com/nodejs/node/issues/5261#issuecomment-197251914) they can feel free to open another PR.

[lance]

@joyeecheung yes, I have essentially dropped the ball on #7005. I agree that this is a bug which needs to be fixed, but I was unable to resolve the Windows failures on CI and could not get any real resolution on how to move forward. If you or anyone else has recommendations for resolving this on those Windows builds, I would be happy to pick the PR back up again and run with it. But without that, I am not sure what to do since I really have very little knowledge of Windows systems.

[bzoz]

Fixed in https://github.com/nodejs/node/commit/bb041ea5a0c1860f9dd196eb69a69fd55f0f3675

[mohamedhaded]

you have to open the cmd as administrator and try again with npm install

[ccoenen]

As a blanket statement, that is really bad advice. Please only run commands with administrator privileges or sudo if you _really_ know what you're getting yourself into.

[imthenachoman]

@seishun So, based on what you're saying, node can't read hidden files in Windows? So we just need to leave files un-hidden?

[alidavodii]

hi my friends , go to c:/users/{pc name}/
show hidden file
properties .yarnrc
hidden uncheck
good luck

[imthenachoman]

@alidavodii Yes. But I’m interested in getting Node to work even if the file is hidden in Windows. However, it appears as it isn’t easily possible. Oh well.

[BridgeAR]

It is possible to read hidden files. The file mode just must be set accordingly.

[imthenachoman]

@BridgeAR Even when the file mode allowed read I was getting that EPERM error. I had to unhide the file from Windows to get rid of the error.

[BridgeAR]

@imthenachoman it would be good to get further information about your OS and what code you executed to further look at that. As it stands right now, we can't do anything to improve the situation in case there's indeed a bug left (which might might be).

[imthenachoman]

@BridgeAR I am on Windows 10. But I don't think there is anything that needs to be investigated. If a file is hidden then Node can't access it. In my case I am getting the error when trying to use clasp. If the file in question is hidden (through Windows) I get the EPERM error. If the file in question is not hidden I do not get the error. I don't understand all of the technical aspects but based on what I read it sounds like because of Windows limitations, Node cannot access Windows hidden files. So I think its case closed -- unless my understanding of what I read is wrong.

[BridgeAR]

@imthenachoman ideally we'll have a consistent behavior across all operating systems. I do wonder if it's possible to handle this case transparently for users on Windows. I am not a Windows user though and can't look into it on my own.

[imthenachoman]

I don't really know/use Node.js so I don't know what to look for but if there is something you want me to try, investigate, look at, etc. I can. Like are there more verbose log files anywhere that show what Node was trying to do when it looked for that file?

[dibakar95]

hi my friends , go to c:/users/{pc name}/
show hidden file
properties .yarnrc
hidden uncheck
good luck

What should I do next

[bzoz]

@dibakar95 you should go to yarn issue tracker, this one is for Node