Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Joe,

On Fri, 12 Mar 2021, Joe Lowe wrote:

> 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 obvious difference being that you cannot read those 0-length files.
And you _can_ determine the target from reading .lnk or .desktop 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.

I find your argument unconvincing.

For all practical purposes, users are likely to want to treat app
execution aliases as if they were symbolic links.

If users want to know more about the app execution alias than just the
path of the actual `.exe` (and that is a rather huge if), _then_ I would
buy your argument that it should be queried via application code.

But for the common case of reading the corresponding `.exe` or accessing
the path? Why should we follow your suggestion and keep making it really
hard for users to get to that information? I really don't get it.

Ciao,
Johannes

>
>
> 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.schindelin@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
> >
>
>