[Bug]: Windows — terminal file links on a mapped network drive fail silently (fs:stat "Access denied: path resolves outside allowed directories") #23018

Operating system

Windows

Orca version

1.4.211

Details

Summary: clicking a terminal file link that lives on a mapped network drive (X: = SMB share mapped with net use) shows the link popover, but both "Open file" and "Open with default app" do nothing. No toast, nothing in the console. Text files sometimes open; images/PDFs never do.

Calling the same steps the click handler runs, from DevTools, shows where it stops:

So the main-process open path works fine for the drive-letter spelling; only the allow-list check in fs:stat rejects it, and the renderer's terminal-link handler swallows the error (try { authorize; stat } catch { return }), which is why the click is a silent no-op.

Likely cause: authorizeExternalPath records path.resolve(p) and fs.realpathSync(p) (the JS implementation, which does not resolve drive mappings, so both are X:\…), while the allow-list check canonicalizes with the native fs.promises.realpath, which on Windows resolves a mapped drive to its UNC form \nas\share\…. The canonical path is then not in the allow-list. A local symlink pointing at the share fails the same way (its realpath is also UNC).

Related: #11183 (mapped drives canonicalized to UNC), #21172 (same "Access denied" from NFD/NFC mismatch on macOS — same class of canonicalization mismatch), #18268.

Steps to reproduce

1. net use X: \server\share on Windows.
2. In an Orca terminal, print X:\share\some\image.png.
3. Click the link → choose either popover action. Nothing happens.
4. DevTools console: await window.api.fs.authorizeExternalPath({targetPath:'X:/share/some/image.png'}); await window.api.fs.stat({filePath:'X:/share/some/image.png'}) → Access denied. Same with //server/share/some/image.png → ok.

Expected
Either accept the drive-letter form (add the native-realpath canonical form to the allow-list when authorizing), or surface the error instead of silently ignoring it.

Workaround
Print NAS paths as forward-slash UNC: //server/share/…. That spelling is linkified and opens. (\server\share\… with backslashes is not linkified at all.)