Why does resolveMainPath wind up trying to lstat my "User" folder in Windows?

[iansul-ms]

I'm working on an app that starts a Node.exe process in an Azure Service Fabric Service. The Node.exe process is run with limited permissions (NETWORK SERVICE), and I find that when I try to run the app with Node.exe under service fabric I get this error

node:internal/fs/utils:347    throw err;
    ^

Error: EPERM: operation not permitted, lstat 'C:\\Users\\foo'
    at Object.realpathSync (node:fs:2552:7)
    at toRealPath (node:internal/modules/cjs/loader:405:13)
    at Module._findPath (node:internal/modules/cjs/loader:561:22)
    at resolveMainPath (node:internal/modules/run_main:19:25)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:75:24)
    at node:internal/main/run_main_module:17:47 {
  errno: -4048,
  syscall: 'lstat',
  code: 'EPERM',
  path: 'C:\\\\Users\\\\foo'
}

Node.js v18.6.0

The app runs correctly from the command line, likely because from the command line it's running with permissions to access that directory. My question is, why is it trying to lstat that directory? I've fully specified the javascript file that holds my app, which has been webpacked. Since it runs from the command line, I know that it is able to load the modules it needs, none of which should actually be coming from an external file because it has been webpacked (except maybe internal modules, not sure how those work).

I don't think I should need to grant NETWORK SERVICE access to that user directory, that's not the right solution.

I can sort of debug by doing --inspect-brk, but it only lets me break when the err is thrown, so I can't step into Object.realpathSync() to see why it tries to do that lstat.

[aduh95]

You might be able to workaround the issue by using --preserve-symlinks-main (and/or --preserve-symlinks). Hopefully the docs explains why it's doing that well enough:

By default, when Node.js loads a module from a path that is symbolically linked to a different on-disk location, Node.js will dereference the link and use the actual on-disk "real path" of the module as both an identifier and as a root path to locate other dependency modules.

[iansul-ms]

Thanks that solved it!

When I initially read the --preserve-symlinks documentation I read it as "respect" the symbolic links, e.g., follow them, but upon closer reading I think I understand how it works and how it solved the problem.