readdirSync fails on Windows (using Apple Boot camp) when accessing a OSX drive

[bjarnij]

• Version: v4.5.0
• Platform: Windows 10 64 bit (Running on a Mac using Apple Boot camp)
• Subsystem: fs

When running Windows on Mac using Apple Boot camp, readdirSync fails when accessing the OSX drive.
This is the error I got:

Error: UNKNOWN: unknown error, scandir 'D:\usr\bin'
    at Error (native)
    at Object.fs.readdirSync (fs.js:808:18)
    ...

Here is a code example:

var fs = require('fs');

var fullPath = "D:\\usr\\bin";

console.log("The location: "  + fullPath + " contains the following: ");
fs.accessSync(fullPath, fs.F_OK);
var files = fs.readdirSync(fullPath);
for (var i in files) {
    console.log("  " + files[i]);
}

The same code works fine when accessing the Windows Boot camp drive instead and when running on OSX...

[bjarnij]

I tried Version: v6.6.0 too and it was the same:

fs.js:951
  return binding.readdir(pathModule._makeLong(path), options.encoding);
                 ^

Error: UNKNOWN: unknown error, scandir 'D:\usr\bin'
    at Error (native)
    at Object.fs.readdirSync (fs.js:951:18)

[eldyvoon]

Have the same problem :(

[bnoordhuis]

Node (or rather, libuv) uses CreateFileW(FILE_LIST_DIRECTORY | SYNCHRONIZE) + NtQueryDirectoryFile() to read directories. If I had to venture a guess, it's that the Windows HFS+ driver doesn't (properly?) support that.

I have no way to test myself but if you want to debug this, I'd start by instrumenting fs__scandir() in deps/uv/src/win/fs.c. A few well-placed printf statements can probably tell you what is going on.

[Eugeny]

Latest official Node.js build now simply crashes instead of returning error.

[Trott]

@refack Are you actively working on this? Is a help wanted label appropriate?

@Eugeny @bjarnij or anyone else: Can anyone confirm that this is still happening with Node.js 8.2.1? (I imagine it is, but might as well confirm since this has been dormant for 3 months.)

[bnoordhuis]

We might as well close this as it's unlikely to be a Node.js bug. Good idea, bad idea?

[Eugeny]

Unfortunately, I don't have any Macs at my disposal at the moment.

@bnoordhuis how exactly is this not a Node bug? At least in Node 7, it's a regression from a returned error to a hard crash.

[bnoordhuis]

Define 'hard crash'?

[Eugeny]

A segmentation fault aka "Application stopped working"

[bnoordhuis]

How did you establish it was caused by fs.readdirSync() and not, for example, a native add-on?

[Eugeny]

Yes, I've been debugging the Node process itself and it crashed somewhere inside the fs module implementation. That's how I found this github issue. I can't recall exact details but I can try to find the exact location again next week.

[refack]

@refack Are you actively working on this? Is a help wanted label appropriate?

Not actively working on this, assigned myself just to keep track.
IMHO although it segfaults, it is an edge case (Windows via Bootcamp, accessing a macOS volume), hence it requires a complicated set up to reproduce.
_{(I have limited access to mac hardware, and I can't bootcamp it, if anyone want to donate some hardware, it will be very helpful /cc @apple ;)}

RE keeping this open — personally I'm +1 on keeping this open since the comments indicate there is a issue here, and I can't think of different way to keep track (not a TODO comment nor a know_issue.js test).

/cc @nodejs/platform-windows @nodejs/platform-macos if anyone has spare cycles PTAL.

[bnoordhuis]

@Eugeny A debugger backtrace would help.

[Eugeny]

Here's what I got:

It seems to be this line: https://github.com/nodejs/node/blob/v7.4.0/deps/uv/src/win/fs.c#L906 (the array lookup), but I'm not 100% sure of it.

Seems like the info ptr is junk because next_entry_offset was junk in the previous iteration

[Eugeny]

Actually, I'm sure of it. wchar_len was optimized away into RSI here.

[refack]

@Eugeny a core dump would be nice to have. Although I think a more general solution might be based on using Windows' I/O manager - #8897 (comment)

[bnoordhuis]

@Eugeny Is that with Node v7.4.0? What does the latest v8.x do? v7.x is out of support.

[apapirovski]

@refack do you want to keep this open? There has been no movement in a while, no new info and it's a pretty extreme edge case.

[bnoordhuis]

I'll close this. The UNKNOWN error is with 99.9% certainty not our bug and the crash was in an eol'd version of node. If someone has information to the contrary, please leave a comment.

[jorangreef]

@refack I think this should be re-opened.

We received this from an app running v7.9.0 on a user's machine today:

Error: UNKNOWN: unknown error, scandir 'C:\Users\Red act Ted\Redacte (Redacte Redact)\Redactedre\Reda\REDA\Redact Redac Redactedredacte'

We received the error several times in the same process and then Node crashed.

It's just a regular C drive running on real Windows, no VM, nothing special.

I don't think libuv's fs__scandir has had any changes since Node v7.9.0 even if Node v7.9.0 is out of support so this might still be an issue?

I can collect more information from the user's machine tomorrow.

[bnoordhuis]

EOL is EOL but happy to reopen if it reproduces with the latest v8.x or v9.x and is otherwise the same issue (readdirSync, Windows, HFS.)