Repository navigation
fs.stat or fs.lstat throws unknown error on some files (reparse point) #33024
Description
- Version: v12.16.2
- Platform: 64 bit Microsoft Windows 10 [Version 10.0.18362.778]
- Subsystem: fs
What steps will reproduce the bug?
- Check if
%USERPROFILE%\AppData\Local\Microsoft\WindowsAppsexists. - Install https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
- Call
fs.statSync("c:\\Users\\kanadig\\AppData\\Local\\Microsoft\\WindowsApps\\python.exe")
How often does it reproduce? Is there a required condition?
This repros 100%, make sure you are calling it on the files under %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\ with 0 size.
What is the expected behavior?
Should not throw exception.
What do you see instead?
> fs.statSync("c:\\Users\\bpasero\\AppData\\Local\\Microsoft\\WindowsApps\\GameBarElevatedFT_Alias.exe")
Thrown:
{ Error: UNKNOWN: unknown error, stat 'c:\Users\bpasero\AppData\Local\Microsoft\WindowsApps\GameBarElevatedFT_Alias.exe'
at Object.statSync (fs.js:855:3)
errno: -4094,
syscall: 'stat',
code: 'UNKNOWN',
path:
'c:\\Users\\bpasero\\AppData\\Local\\Microsoft\\WindowsApps\\GameBarElevatedFT_Alias.exe' }
> fs.lstatSync("c:\\Users\\bpasero\\AppData\\Local\\Microsoft\\WindowsApps\\GameBarElevatedFT_Alias.exe")
Thrown:
{ Error: UNKNOWN: unknown error, lstat 'c:\Users\bpasero\AppData\Local\Microsoft\WindowsApps\GameBarElevatedFT_Alias.exe'
at Object.lstatSync (fs.js:845:3)
errno: -4094,
syscall: 'lstat',
code: 'UNKNOWN',
path:
'c:\\Users\\bpasero\\AppData\\Local\\Microsoft\\WindowsApps\\GameBarElevatedFT_Alias.exe' }
>
Activity
bzoz commentedon Apr 23, 2020
Those are
IO_REPARSE_TAG_APPEXECLINKreparse points and currently, libuv does not support those. Nothing we cannot fix 😉win, fs: add IO_REPARSE_TAG_APPEXECLINK support
win, fs: add IO_REPARSE_TAG_APPEXECLINK support
win, fs: add IO_REPARSE_TAG_APPEXECLINK support
win, fs: add IO_REPARSE_TAG_APPEXECLINK support
bzoz commentedon Apr 29, 2020
A fix for this landed in libuv, it should make it way to Node rather soon.
The stat calls will probably still not work though. Those links usualy point to the
C:\Program Files\WindowsAppsfolder that is not normally accessible, even after elevating.lstatshould be fine, the added libuv test lstats the%LOCALAPPDATA%\Microsoft\WindowsAppsfolder.bzoz commentedon May 22, 2020
Fixed by #33446
karthiknadig commentedon Jan 19, 2021
This is not fixed. I can repro it with the latest release.
win, fs: add IO_REPARSE_TAG_APPEXECLINK support
win, fs: add IO_REPARSE_TAG_APPEXECLINK support
vtjnash commentedon Jan 1, 2026
In the years since this fix was merged here (while working on the followup fixes), research has uncovered that dotNet and powershell were asked to revert their equivalent fix in their respective libraries and instead report to the user that these symlinks are not symlinks but rather regular, empty files which the user does not have the ability to access: PowerShell/PowerShell#19760 (comment)
That opens the question of whether libuv should also have reverted the fix too? It might be helpful if anyone could ping someone at Microsoft at the AppExecLinks team (maybe @SteveL-MSFT, since it looks like you made both the original PR and the revert PR) to provide documentation on this interface and a PR for how nodejs should handle this, since right now nodejs is relying on this interface being stable–whether documented or not, since most interfaces aren't documented.