From: Joe Lowe <joe@pismotec.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: cygwin-patches@cygwin.com
Subject: Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Date: Sat, 13 Mar 2021 19:41:25 -0800 [thread overview]
Message-ID: <86c7c1b6-06f9-9e60-e9d7-072b6e8c806f@pismotec.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2103140115180.50@tvgsbejvaqbjf.bet>
Hi Johannes,
I agree on the usefulness to the user of showing appexec target
executable as symlink target. But I am uncertain about the effect on code.
One example: Any app that is able to archive/copy posix symlinks will
convert the appexec to a symlink and silently drop the appexec data.
Whether this is a significant issue depends on if most/all relevent
store apps function the same when the executable is exec-ed directly vs
via the appexec link.
Another example: Much code exists in the field that intentionally
detects symlinks, dereferences, and works directly on the target. This
may not be an issue, if most/all relevent store apps function the same
when the executable is exec-ed directly vs via the appexec link.
Joe L.
On 3/13/2021 4:21 PM, Johannes Schindelin wrote:
> 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
>>>
>>
>>
next prev parent reply other threads:[~2021-03-14 3:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 15:11 Johannes Schindelin
2021-03-12 17:03 ` Joe Lowe
2021-03-14 0:21 ` Johannes Schindelin
2021-03-14 3:41 ` Joe Lowe [this message]
2021-03-15 3:19 ` Johannes Schindelin
2021-03-15 19:04 ` Hans-Bernhard Bröker
2021-03-22 15:22 ` Johannes Schindelin
2021-03-22 21:54 ` Hans-Bernhard Bröker
2021-03-23 9:30 ` Corinna Vinschen
2021-03-24 18:55 ` Hans-Bernhard Bröker
2021-03-24 20:58 ` Ken Brown
2021-03-26 1:29 ` Hans-Bernhard Bröker
2021-03-15 10:17 ` Corinna Vinschen
2021-03-15 19:52 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86c7c1b6-06f9-9e60-e9d7-072b6e8c806f@pismotec.com \
--to=joe@pismotec.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=cygwin-patches@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).