fs.realpath fails to provide a canonical path for mountpoints on windows.

[BobFrankston]

Version

20

Platform

Windows

Subsystem

fs

What steps will reproduce the bug?

Windows has the concept of mounting file systems as directories. These are different from symbolic links:

 <JUNCTION>     q [\??\Volume{190aa41f-dd2f-4c93-911c-44b20b305e33}\]

In this case, q points to the q:\ drive. If I do fs.statSync("q:\") and "c:\drives\q\w") I get the same dev and ino values, but fs.realpathSync does not resolve them to the same name. This is a subtle problem because who's to say what the real name is? Nonetheless, they should resolve to the same path. I can argue the q:\ form is canonical. For now, I'll rely on dev/ino for uniqueness.

At least, I wish I could, but WSL shows a different device for /mnt/q vs q:\

Ain't computers fun? Or, at least, perverse. It's even worse for network paths.

How often does it reproduce? Is there a required condition?

100 repro - just use mountvol in windows

What is the expected behavior? Why is that the expected behavior?

realpath should produce the one "real" path -- it doesn't.

What do you see instead?

I see the path through a mount point is does not resolve to the same name as one going direct to the base file system.

Additional information

Some edge cases, like local mounts might be resolvable, but the general case requires using dev/ino. The documentation should note the problem and acknowledge the limits.

[bnoordhuis]

Not a Windows user so I can't test but does fs.realpath.native(path) produce the right result? If the answer is "no" then I don't think there is much we can do.

[BobFrankston]

Oops -- I made a mistake in this response and was responding to a thread from another context so I removed it

[bnoordhuis]

That's moving the goalposts vis-a-vis your original report quite a bit, isn't it? It's also a little too open-ended to be actionable unless you have specific, concrete suggestions for improvement.

[BobFrankston]

Apologies my mistake because I thought it was part of a different discussion.

.native actually did the right thing! Thanks. Will investigate more.

I am curious about why .native produced different results.

[bnoordhuis]

fs.realpath.native is basically the realpath() from libc, fs.realpath is node's own cross-platform implementation (with higher limits on symlinks, etc.)

[conartist6]

In addition to junctions, subst can be used to create "DOS devices", e.g. mappings from D: to C:\Develpment or something. These are also not resolved, and cause a similar issue in resolve. Strangely the fix for the issue in resolve was exactly the opposite: forcing windows to use non-native realpath instead of realpath.native.