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=" "

[mrnerdhair]

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?

[mrnerdhair]

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

[mrnerdhair]

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 notifications@github.com
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
#5261 (comment).