镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

fs.stat or fs.lstat throws unknown error on some files (reparse point) #33024

Description

@karthiknadig
  • Version: v12.16.2
  • Platform: 64 bit Microsoft Windows 10 [Version 10.0.18362.778]
  • Subsystem: fs

What steps will reproduce the bug?

  1. Check if %USERPROFILE%\AppData\Local\Microsoft\WindowsApps exists.
  2. Install https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
  3. 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' }                           
>     

Additional information

See microsoft/vscode#95828

Activity

  1. bzoz commented on Apr 23, 2020

    @bzoz
    Contributor

    Those are IO_REPARSE_TAG_APPEXECLINK reparse points and currently, libuv does not support those. Nothing we cannot fix 😉

  2. added
    libuvIssues and PRs related to the libuv dependency or the uv binding.
    windowsIssues and PRs related to the Windows platform.
    confirmed-bugIssues and PRs for confirmed bugs.
    on Apr 23, 2020
  3. bzoz commented on Apr 29, 2020

    @bzoz
    Contributor

    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\WindowsApps folder that is not normally accessible, even after elevating. lstat should be fine, the added libuv test lstats the%LOCALAPPDATA%\Microsoft\WindowsApps folder.

  4. bzoz commented on May 22, 2020

    @bzoz
    Contributor

    Fixed by #33446

  5. karthiknadig commented on Jan 19, 2021

    @karthiknadig
    Author

    This is not fixed. I can repro it with the latest release.

  6. vtjnash commented on Jan 1, 2026

    @vtjnash
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    confirmed-bugIssues and PRs for confirmed bugs.libuvIssues and PRs related to the libuv dependency or the uv binding.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions