stat.isFIFO() is wrongly marked as always false on Windows, even when piping into a node process

[vladfrangu]

Version

v22.14.0

Platform

Microsoft Windows NT 10.0.26120.0 x64 [although this is on ARM64]

Subsystem

No response

What steps will reproduce the bug?

Running echo '{}' | node -e 'console.log(require("fs").fstatSync(0).mode)' in PowerShell (as cmd doesn't seem to support pipes via the usual syntax) returns 4096, and checking fs.constants, S_IFIFO is set to 4096.

How often does it reproduce? Is there a required condition?

Seems to be all the time on Windows when you try to pipe something in, which is due to a (I assume legacy?) check here:

node/lib/internal/fs/utils.js

Lines 538 to 541 in c3b6f94

	if (isWindows && (property === S_IFIFO || property === S_IFBLK ||
	property === S_IFSOCK)) {
	return false; // Some types are not available on Windows
	}

What is the expected behavior? Why is that the expected behavior?

On Windows, stat.isFIFO() should correctly handle pipes and stat.isFIFO() should correctly return true when piped in

What do you see instead?

stat.isFIFO() always returns false on Windows, even if the mode has the flag set

Additional information

I would love to submit a PR to fix this, but I am not sure if those checks are there for a reason or for legacy purposes (it seems that at least the S_ISFIFO is now exposed but it wasn't before [?]), and if it can be edited safely.

[bnoordhuis]

It's the other way around: fstat shouldn't report S_IFIFO because there are no FIFOs on Windows. Different semantics.

That it does stems from a small bug (maybe not even a bug) in libuv where it sets the st_mode field for named pipes in best-effort fashion to S_IFIFO as that is the closest equivalent on Windows.

Compare: UNIX systems have AF_UNIX sockets, pipes and FIFOs. Windows has named pipes and, as of Windows 10, AF_UNIX sockets.

[vladfrangu]

Ouch... Thanks for the explanation! So then I take it that technically piped input working in Powershell is because of powershell and not Windows...

I'm not sure how I can help further with this, as this was the only way I found to actually detect if something will try to pipe into stdin on Windows. I guess in my project I'll fallback to a timeout trying to read from stdin?

[bnoordhuis]

Node internally uses guessHandleType(0) to detect if stdin refers to a pipe, tty, file, etc. but that's not exposed to user JS code.

It's in lib/internal/util.js and is a wrapper around libuv's uv_guess_handle() function. You could try opening a PR that adds it to util, fs or os (all three make some degree of sense.)

W.r.t. my previous comment: after giving it some more thought, I think libuv is correct to report S_IFIFO for named pipes because pipes on UNIX are also S_IFIFO, even though a pipe is different from an actual FIFO created with mkfifo(1).

[vladfrangu]

Well this is fun

I feel like maybe I can PR this under os like you suggested (to me it makes the most sense, especially since handles can be more than just files)? Is that something you guys would be ok with exposing to users / would it cause any issues if, in the future, that function needs to be changed and/or broken/removed?

[bnoordhuis]

The underlying libuv API is solid and stable. Seems like a safe addition to node's API.