I am skeptical about this patch (part 1), interposing appexec reparse point data as symlinks for cygwin applications.

The appexec reparse point data is essentially an extended attribute holding data that is used by CreateProcess(), more like a windows .lnk file or an X11 .desktop file, not like a posix symlink. M$ just chose an unnecessarily obtuse way to store the files data. This reminds me of old Macintosh zero length font files.

The useful function of the patch would seem to be as a way to display a portion of the data in shell directory listings for the user. I suggest this function is better provided by updated application code.


The patch part 2 seems entirely appropriate.


Joe L.


On 2021-03-12 07:11, Johannes Schindelin via Cygwin-patches wrote:
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.schinde...@gmx.de>
---
  winsup/cygwin/path.cc | 24 ++++++++++++++++++++++++
  1 file changed, 24 insertions(+)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index f3b9913bd0..63f377efb1 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2538,6 +2538,30 @@ check_reparse_point_target (HANDLE h, bool remote, 
PREPARSE_DATA_BUFFER rp,
        if (check_reparse_point_string (psymbuf))
        return PATH_SYMLINK | PATH_REP;
      }
+  else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
+    {
+      /* App execution aliases are commonly used by Windows Store apps. */
+      WCHAR *buf = (WCHAR *)(rp->GenericReparseBuffer.DataBuffer + 4);
+      DWORD size = rp->ReparseDataLength / sizeof(WCHAR), n;
+
+      /*
+         It seems that app execution aliases have a payload of four
+        NUL-separated wide string: package id, entry point, executable
+        and application type. We're interested in the executable. */
+      for (int i = 0; i < 3 && size > 0; i++)
+        {
+         n = wcsnlen (buf, size - 1);
+         if (i == 2 && n > 0 && n < size)
+           {
+             RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof(WCHAR));
+             return PATH_SYMLINK | PATH_REP;
+           }
+         if (i == 2)
+           break;
+         buf += n + 1;
+         size -= n + 1;
+       }
+    }
    else if (rp->ReparseTag == IO_REPARSE_TAG_LX_SYMLINK)
      {
        /* WSL symlink.  Problem: We have to convert the path to UTF-16 for
--
2.30.2

Reply via email to