Can't open hidden files in 'w' mode on Windows - document, fix, or do nothing?

[seishun]

• Version: all
• Platform: Windows
• Subsystem: fs

Trying to open a hidden file on Windows in 'w' mode throws EPERM:

> fs.openSync('hidden.txt', 'w')
Error: EPERM: operation not permitted, open 'C:\hidden.txt'
    at Object.fs.openSync (fs.js:651:18)
    at repl:1:4
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:433:10)
    at emitOne (events.js:120:20)
    at REPLServer.emit (events.js:210:7)
    at REPLServer.Interface._onLine (readline.js:278:10)

This matches the behavior of Microsoft C runtime library:

#include <cstdio>
#include <cerrno>

int main()
{

	FILE* f = fopen("hidden.txt", "w");
	if (f) {
		puts("success");
	} else if (errno == EACCES) {
		perror("EACCES");
	} else {
		perror("something else");
	}
}

Output if "hidden.txt" is hidden:

EACCES: Permission denied

And it matches the behavior of Python since it purportedly uses _wfopen under the hood:

>>> open("hidden.txt", "w")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied: 'hidden.txt'

However, this behavior has caused at least two issues down the road:

• Error: EPERM: operation not permitted, open 'C:\Users\username\.node_repl_history' #5261 (fixed in repl: support hidden history file on Windows #12207)
• Windows: Cannot save hidden files microsoft/vscode#931 (PR submitted in Use r+ with truncation when saving existing files microsoft/vscode#31733)

So, my questions are:

• Does Node.js really have to match CRT's behavior here? Would anything break if it started allowing opening hidden files in 'w' mode?
• If we can't or don't want to "fix" this, do we want to document this behavior, or do we just say "does the same thing CRT does"?

[bnoordhuis]

Does Node.js really have to match CRT's behavior here?

I'm not 100% sure but reading fs__open() in deps/uv/src/win/fs.c (which uses the CreateFile NT API, not the CRT), I don't see anything that suggests it's a policy enforced by libuv.

[seishun]

It doesn't enforce it explicitly, no. It just never passes the FILE_ATTRIBUTE_HIDDEN flag, causing CreateFile to fail when called on a hidden file.

[bnoordhuis]

I don't know if that is fixable. Passing it by default is not an option and retrying the CreateFile() call on error is race-y. All signs seem to point to 'documentation fix.'

[tniessen]

It seems like the only way to write to hidden files (without setting FILE_ATTRIBUTE_HIDDEN) is by setting the disposition to either TRUNCATE_EXISTING or CREATE_NEW, and I don't think it is possible to use these values in fs.open() 😞

[bnoordhuis]

Hm, does that mean 'wx' instead of 'w' works?

[seishun]

Passing it by default is not an option

Why not? FILE_ATTRIBUTE_HIDDEN works for both hidden and non-hidden files.

Hm, does that mean 'wx' instead of 'w' works?

No, 'wx' maps to O_TRUNC | O_CREAT | O_WRONLY | O_EXCL, which maps to CREATE_NEW, which fails if the file already exists.

[tniessen]

Why not? FILE_ATTRIBUTE_HIDDEN works for both hidden and non-hidden files.

But won't this cause new files to be hidden?

[seishun]

Indeed it does... 🤦‍♂️

[bnoordhuis]

So, what is the consensus here? Documentation fix? Any volunteers?

[bnoordhuis]

Ping @seishun.

edit: is #15409 the doc fix?

[seishun]

Yes, it is.

[tniessen]

So the question at hand is whether we want to deviate from CRT here or not. If we do, this needs an upstream implementation, and I am not sure an atomic solution exists.