fs.lstat and fs.readlink not recognizing symbolic links in Windows

[kshetline]

I'm accessing an Unraid share on Windows using SMB. Windows Explorer can follow symbolic links found on this share, so I know that there's not some total failure of the SMB protocol on Windows to handle symbolic links.

fs.lstat(), and isSymbolicLink(), however, called on the returns stats, always tells me false. (People have run into this problem using stat instead of lstat, but that's not the issue here.) fs.readlink() results in an error.

I can assure you this really is a symbolic link:

...and that double-clicking on the 007 folder in Explorer properly reveals the target of the link.

I'm using Node.JS v18.17.1 on Windows 11. I get the same problem using Node.js in WSL, looking at the same mounted SMB share. WSL itself doesn't see the link as a link.

Is this a Node.js bug? Is there some option or work-around that I'm missing?

[kshetline]

Apparently I was wrong about Explorer somehow being aware of symlinks, and being able to use them.

What's going on is that, as far as Windows is concerned, or any consumer of the SMB volume, the symlink to a file IS that file, and the symlink to a directory IS that directory. It's impossible to distinguish between a link and the target to that link.

Fortunately for me, the code I'm writing, while being tested on Windows, will run in a Linux environment on Docker when deployed. For testing purpose, this ugly hack helps:

find . -type l -exec echo {} \; -exec readlink {} \; > symlinks.txt

I run the above command on my Unraid server to build a symlink lookup at the root of the volume. Instead of using lstat and readlink directly, I go through a utility function that uses real lstat and readlink in Linux, which will be accessing an NFS share, not SMB, or, in the Windows environment, I use the symlinks.txt lookup file.