Repository navigation
stat.isFIFO() is wrongly marked as always false on Windows, even when piping into a node process #57603
Description
Activity
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.
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?
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).
Well this is fun
I feel like maybe I can PR this under
oslike 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?Reacted by Gürgün DayıoğluThe underlying libuv API is solid and stable. Seems like a safe addition to node's API.
Reacted by Vlad Frangu, ExE Boss and Juan JoséThis issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.Sorry stale boat, the PR is still up
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.Maybe add the never‑stale label to this?
- added a commit that references this issue
on Jul 24, 2026 Sorry stale bot 2, the PR is alive and freshly rebased
- added a commit that references this issue
on Aug 25, 2026
Version
v22.14.0
Platform
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 checkingfs.constants,S_IFIFOis set to4096.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
What is the expected behavior? Why is that the expected behavior?
On Windows,
stat.isFIFO()should correctly handle pipes andstat.isFIFO()should correctly returntruewhen piped inWhat do you see instead?
stat.isFIFO()always returns false on Windows, even if the mode has the flag setAdditional 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.