Repository navigation
fs.stat or fs.lstat throws unknown error on some files (reparse point) #33024
Description
Activity
Those are
IO_REPARSE_TAG_APPEXECLINKreparse points and currently, libuv does not support those. Nothing we cannot fix 😉- addedlibuvIssues and PRs related to the libuv dependency or the uv binding.Issues and PRs related to the libuv dependency or the uv binding.windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.confirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Apr 23, 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.Fixed by #33446
This is not fixed. I can repro it with the latest release.
- added a commit that references this issue
on Jul 23, 2025 - added a commit that references this issue
on Dec 16, 2025 A fix for this libuv/libuv#2812, it should make it way to Node rather soon.
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.
What steps will reproduce the bug?
%USERPROFILE%\AppData\Local\Microsoft\WindowsAppsexists.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?
Additional information
See microsoft/vscode#95828