On 8/15/22, Gisle Vanem via Python-list <python-list@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(). -- https://mail.python.org/mailman/listinfo/python-list
