process.cwd() casing inconsistent across platforms

[Urthen]

• Version: Node 6.4
• Platform: OSX, Windows 10 64bit
• Subsystems: process, path

In various case-insensitive platforms - namely, Windows and OSX - it is possible to cd into an incorrectly-cased path. Node handles this differently on Windows than it does in OSX when attempting to resolve process.cwd(). This affects other modules - namely, how path.resolve() cases its absolute paths.

In OSX, process.cwd() resolves to the correctly cased path, regardless of which path you have cded into. I believe this to be correct behavior.

~/my-app$ node
> process.cwd()
'/Users/michael.pratt/my-app`
~/my-app$ cd ../My-app
~/My-app$ node
> process.cwd()
'/Users/michael.pratt/my-app`

In Windows default console, it is not possible to cd into an incorrect path. However, using PowerShell or the new Bash for Windows, it is possible, but process.cwd() resolves to the incorrect path casing - not matching what is on disk.

PS C:\Users\Michael Pratt\my-app> node             
> process.cwd()                                   
'C:\\Users\\Michael Pratt\\my-app'                 
PS C:\Users\Michael Pratt\my-app> cd ../My-app   
PS C:\Users\Michael Pratt\My-app> node             
> process.cwd()                                   
 'C:\\Users\\Michael Pratt\\My-app'  

Again, I feel the OSX behavior is correct, as it matches what is on the filesystem.

[silverwind]

Nice find, I agree the behaviour is wrong there. Likely a Windows API issue. The fact that Powershell displays the "wrong" path doesn't give much hope, though.

cc: @nodejs/platform-windows @saghul.

[seishun]

I believe the behavior is correct, as it returns the path returned by Windows. Regarding the "real path" versus "different case path" issue, I've expressed my opinion in #2443 (comment). To summarize, if you don't expect process.cwd() to return the real path if symlinks are involved, then you shouldn't expect it to return the "correct case" path either.

[silverwind]

I think it's generally adviceable to do case-insensitive path comparision on case-insensitive file systems. Maybe we should include that in docs somewhere?

[Urthen]

Unfortunately, that raises problems when operating cross-platform.

The context here is that on a case-insensitive system (at least in Webpack), it is possible to do import Foo from '../foo' and/or import Foo from '../Foo'. This results in errors on a case-sensitive system. I've developed a Webpack plugin to check for these incorrect cases. If you have cded into the incorrectly-cased path on Windows, it (correctly, IMO) detects that absolute paths returned by path.resolve() do not match what is on the filesystem.

Right now I'm planning on working around this by checking what process.cwd() returns and accepting that as a "valid" case with the assumption that the user has probably cded into the wrongly-cased directory, but I'd prefer a more robust solution in node for path.resolve() to return the correct path.

[saghul]

For process.cwd() we use uv_cwd, which is implemented as a simp,e wrapper over GetCurrentDirectoryW, whatever case it returns.

IIRC the problem on Windows is that while NTFS is case sensitive, the Windows API is not, so ¯_(ツ)_/¯

[Urthen]

To quote a coworker, if Node is supposed to be cross-platform, it should compensate for platform inconsistencies. Much of the path module is there specifically to resolve these kind of platform inconsistencies, in fact.

I admit this is an edge case, and one that I can probably work around, and even that there is logic in reporting the CWD that the OS reports regardless of whether it is the correct case. In this case that this cannot be resolved, would you at least accept a documentation pull request warning about the cross-platform inconsistency on both process.cwd() and path.resolve()?

[saghul]

But which is the correct case if both are valid then? Have you tested with OSX with case-sensitive HFS? Last: in order to fix this Node would need to know what the correct case is (when on Windows), since NTFS is case sensitive. But how do we know?

[silverwind]

@saghul brings up a good point. I'm reminded of #2165 which is of a very similar nature, but in the unicode normalization case, it's at least somewhat accepted that the NFC form is superior to NFD. Not something that could be said about letter case 😉.

[seishun]

But how do we know?

By using GetFinalPathNameByHandle. However, I don't think it should be process.cwd()'s job to "normalize" the path. If the user wants the physical path, they should call fs.realpath themselves.

...Or so it should be in an ideal world. Unfortunately, the JS implementation of fs.realpath doesn't call GetFinalPathNameByHandle, so the casing remains as-is. During the brief period when Node.js used native realpath, it was changed to the "physical" casing:

> fs.realpathSync('C:\\Users\\Nikolai\\desktop')
'C:\\Users\\Nikolai\\Desktop'
> process.version
'v6.3.1'

[Urthen]

I can't concur that correct case isn't determinate. Even on a case-insensitive system, while many different case combinations might be valid as representations, only one is correct - that is, what the filesystem is actually storing it as. It's the difference between require('./package.json') and require('./PACKAGE.json') - while both work on a case-insensitive FS, they won't work on a case-sensitive one.

Also, as a side note, I just found out possibly even further evidence in Node itself that case-correctness really does matter. require('./PACKAGE.JSON') doesn't work, because Node is apparently checking for a case-sensitive .json extension.

[Urthen]

As for the "how to determine" question, it's been resolved a couple different ways. The true-case-path lib uses glob to determine the correct path. My plugin uses fs.readdirSync recursively along the path and some intelligent caching to reduce filesystem operations. Neither I would suggest doing on every path.resolve call, but it might be able to be done at startup time to populate a correctly-cased process.cwd().