Closed
Description
Version
23.2.0
Platform
Microsoft Windows NT 10.0.22631.0 x64
Subsystem
fs
What steps will reproduce the bug?
This regressed in 23.2:
PS C:\Users\conno> fnm use 23.1
Using Node v23.1.0
PS C:\Users\conno> node
Welcome to Node.js v23.1.0.
Type ".help" for more information.
> fs.readdirSync('\\\\.\\pipe').length
510
PS C:\Users\conno> fnm use 23.2
Using Node v23.2.0
PS C:\Users\conno> node
Welcome to Node.js v23.2.0.
Type ".help" for more information.
> fs.readdirSync('\\\\.\\pipe').length
Uncaught Error: ENOTDIR: not a directory, scandir '\\.\pipe'
at Object.readdirSync (node:fs:1499:26) {
errno: -4052,
code: 'ENOTDIR',
syscall: 'scandir',
path: '\\\\.\\pipe'
}
How often does it reproduce? Is there a required condition?
100%
What is the expected behavior? Why is that the expected behavior?
The contents of \\.\pipe
should be able to be read as a directory.
What do you see instead?
ENOTDIR when enumerating \\.\pipe
Additional information
This causes js-debug's debugger to break #55948. There is not really a good workaround.
Windows lacks any kind of API aside from this for checking the existence of a named pipe--as exists
/ stat
actually connects to the pipe--so listing \\.\pipe
is a common pattern for Windows applications who need to check (e.g. https://berserkerdotnet.github.io/blog/detecting-namedpipe-exists/)