require fails to load 'package.json' when the module path contains Chinese characters on Windows.

[hokein]

Reproduce steps:

• Create a Chinese-name node module directory that contains a package.json, like

 中文目录
  |-- main.js
  |-- package.json

And the content of package.json:

{
  "name": "test",
  "productName": "test",
  "main": "main.js"
}

• Type require("<Chinese-path>") in iojs, then Error Error: Cannot find module XXX will arise.

It fails on iojs v2.4 and v3.0 rc4, but works on v1.6, I believe a regression issue. What's more, it seems only fails to read the package.json file. If we require a absolute js path(<Chinese-path>/main.js), it loads the module well.

[targos]

just confirmed. The regression appeared with v2.2.0

[targos]

The module resolution fails because it cannot read the package.json file.
I suspect a problem with internalModuleReadFile and unicode paths on Windows.
/cc @bnoordhuis

[bpasero]

@bnoordhuis @trevnorris this is really bad and a huge regression from pre 2.2.0 io.js. I can reproduce the require call to fail easily by having a index.js file sit inside a folder with german umlauts (or any other non ascii character).

This might be less critical for use cases of io.js in server environments and Mac/Linux, but dont forget that e.g. Electron (the shell of the atom editor: https://github.com/atom/electron) is using io.js for all node matters and you can easily end up installing it on a Windows path with special characters.

From looking at the code, it seems to fail inside InternalModuleReadFile (https://github.com/bnoordhuis/io.js/blob/master/src/node_file.cc#L443), maybe in the fopen call. That is also the only place where fopen is being used. Other fs calls like the internal stat call are not failing like that.

[trevnorris]

@bnoordhuis Should Windows use _wfopen() instead?

[bnoordhuis]

I'd use uv_fs_open() + uv_fs_read().

[brendanashworth]

This does seem to be rather bad, I'd consider this a candidate for blocking the 3.1 release, thoughts?