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

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:

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

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.

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.

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.'

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() 😞

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

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.

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

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

Indeed it does... 🤦‍♂️

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

doc: document opening hidden files on Windows

@seishun

Ping @seishun.

edit: is #15409 the doc fix?

Yes, it is.

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.

doc: document opening hidden files on Windows

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

bnoordhuis commented on Jul 31, 2017

seishun commented on Jul 31, 2017

bnoordhuis commented on Jul 31, 2017

tniessen commented on Jul 31, 2017

bnoordhuis commented on Jul 31, 2017

seishun commented on Jul 31, 2017

tniessen commented on Jul 31, 2017

seishun commented on Jul 31, 2017

bnoordhuis commented on Aug 8, 2017

bnoordhuis commented on Sep 21, 2017

seishun commented on Sep 21, 2017

tniessen commented on Sep 21, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions