Persistent Error: Python was not found

[Eryk Sun]

On 8/15/22, Gisle Vanem via Python-list <python-list at python.org> wrote:
> Eryk Sun wrote:
>
>> If the redirector app
>> is run without arguments, it will open the Microsoft Store to install
>> the latest version of the Python store app distribution. Currently
>> that means Python 3.10.
>
> That is true with cmd. But with a shell like 4NT, I get:
>    c:\> "%LocalAppData%\Microsoft\WindowsApps\python.exe"
>    4NT: (Sys) No access to the file.
>     "C:\Users\gvane\AppData\Local\Microsoft\WindowsApps\python.exe"
>
> No matter what I do with this "App Alias" setting.
> What a broken and confusing design this AppX design is.

An app execution alias is a reparse point with the tag
IO_REPARSE_TAG_APPEXECLINK (0x8000001B). Neither the I/O manager no
any driver in the kernel supports this type of reparse point. For
better or worse, this is intentional. As such, if CreateFileW() is
called on an alias without using the flag
FILE_FLAG_OPEN_REPARSE_POINT, the attempt to traverse the link fails
with ERROR_CANT_ACCESS_FILE (1920). Note that Python's os.stat() was
updated to open the reparse point directly in this case instead of
failing. But a lot of applications, in particular non-Microsoft shells
such as MSYS bash (and apparently 4NT) haven't been updated similarly.

Even if the link could be traversed, the target file under
"%ProgramFiles%\WindowsApps" doesn't grant execute access to users
unless they have an access token that includes a WIN://SYSAPPID
attribute that corresponds to the executed app. How this works in
practice when executing an app is that CreateProcessW() handles
ERROR_CANT_ACCESS_FILE by opening the reparse point, reading the
relevant app information, and creating a custom access token that
allows it to execute the app directly via the internal equivalent of
CreateProcessAsUserW().