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