Treat "app execution aliases" as symlinks, and allow executing them #27
Conversation
|
I submitted these patches to the Cygwin mailing list (cover letter is here, unfortunately I forgot to pass the |
|
Are we allowed to use Rtl* functions? |
Look at the context, e.g. msys2-runtime/winsup/cygwin/path.cc Line 2512 in 647dff4 |
|
LGTM from 👀 |
|
For the record, someone raised the concern on the Cygwin mailing list that treating appexeclinks as symlinks might break stuff, e.g. backup/restore software: https://cygwin.com/pipermail/cygwin-patches/2021q1/011253.html I disagree, as Cygwin already interprets several different constructs as symlinks (old-style sysfiles, native symlinks, WSL symlinks, etc) and backup/restore software would not know how to recreate them faithfully, and therefore I deem the objection to miss the mark. Nevertheless, that discussion should probably settle before merging this PR, just in case that I am asked to revise (or drop) the patch: I do not want MSYS2 to deviate unnecessarily from Cygwin. |
When the Windows Store version of Python is installed, so-called "app execution aliases" are put into the `PATH`. These are reparse points under the hood, with an undocumented format. We do know a bit about this format, though, as per the excellent analysis: https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html The first 4 bytes is the reparse tag, in this case it's 0x8000001B which is documented in the Windows SDK as IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to be a corresponding structure, but with a bit of reverse engineering we can work out the format is as follows: Version: <4 byte integer> Package ID: <NUL Terminated Unicode String> Entry Point: <NUL Terminated Unicode String> Executable: <NUL Terminated Unicode String> Application Type: <NUL Terminated Unicode String> Let's treat them as symbolic links. For example, in this developer's setup, this will result in the following nice output: $ cd $LOCALAPPDATA/Microsoft/WindowsApps/ $ ls -l python3.exe lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe' Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Windows Store version of Python (and apparently other Windows Store applications) install a special reparse point called "app execution alias" into the user's `PATH`. These applications can be executed without any problem, but they cannot be read as if they were files. This trips up Cygwin's beautiful logic that tries to determine whether we're about to execute a Cygwin executable or not: instead of executing the application, it will fail, saying "Permission denied". Let's detect this situation (`NtOpenFile()` helpfully says that this operation is not supported on this reparse point type), and simply skip the logic: Windows Store apps are not Cygwin executables (and even if they were, it is unlikely that they would come with a compatible `cygwin1.dll` or `msys-2.0.dll`). This fixes msys2/MSYS2-packages#1943 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I got good feedback from the Cygwin maintainer, sent off v2, and it was applied with two minor modifications as 0631c66. So I cherry-picked it, and I think we're good to go now. |
|
@lazka what should we do with this? Merge, even if v3.2.0 might be just around the corner? |
|
I'd wait for 3.2.0 if you don't mind |
This most notably allows running the Windows Store version of Python directly from MSYS2's Bash (without
cmd /c ...tricks).This fixes msys2/MSYS2-packages#1943