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

["Hans-Bernhard Bröker" <HBBroeker@t-online.de>]

Am 22.03.2021 um 16:22 schrieb Johannes Schindelin:
> On Mon, 15 Mar 2021, Hans-Bernhard Bröker wrote:
>> Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches:

>> That argument might hold more sway if Windows itself didn't quite so
>> completely hide that information from users, too.

> "So completely"? It at least executes them, and it does offer you to turn
> them aliases on and off (see
> https://www.tenforums.com/tutorials/102096-manage-app-execution-aliases-windows-10-a.html)

That's a completely different piece of information than what you want 
Cygwin to show.

> Granted, the user interface has a lot of room for improvement, but if you
> are dead set on finding out what, say, that `idle.exe` app execution alias
> refers to, you can go to `Settings>Apps>Apps & features>App execution
> aliases` and find out that it is owned by the Python 3.7 package. 

Knowing which package that thing came from has essentially nothing to do 
with what its interpretation as a symlink would look like.  Apples and 
Oranges.

> The `fsutil` program, contrary to your claim, is available without WSL:
> https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil

And that very page tells me, in a big "Notice" blurb:

> You must enable Windows Subsystem for Linux before you can run fsutil. Run the following command as Administrator in PowerShell to enable this optional feature:


> One of those under-documented reparse point types is the WSL symbolic
> link, which you will notice are supported in Cygwin, removing quite some
> sway from your argument...

I notice no such thing right now, running the currently available 
release version 3.1.7:

stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error

[other commands that want to show more than just the name behave 
equivalently]

Links made by WSL directly on a Windows filesystem are understood by 
Cygwin.  But that's because WSL uses Windows symlinks in that case.

Microsoft could almost certainly just have used a symlink to implement 
this rather trivial feature.  But for some reason they apparently didn't 
care to explain anywhere, they chose to wildly overcomplicate it, 
inventing a completly type of reparse point.  So for what it's worth, 
that thing _is_not_a_symlink_.  Pretending it is one is bound to cause 
more problems than it solves.

> Well, that's funny: you are talking to one Cygwin user who needs to see
> it. So I feel a bit ignored by you there.

All conclusions based on a single example are wrong.