Hey Corinna, [Sorry for top-posting]
I take it you mean <https://cygwin.com/pipermail/cygwin-patches/2025q4/014403.html>? Then yes, it looks as if we're trying to fix the same issue, even if I have to admit that I wouldn't have begun to have guessed that from the commit message in that mail that the bug is about app execution aliases (regular symbolic links don't have a problem, I don't think, and therefore the message might be considered misleading to a certain extent). For that reason, I _much_ prefer the more verbose description of the problem that I offered in the email you quoted. Also, it looks as if that other proposed patch will always add overhead, not only when the reparse point needs to be handled in a special way. Given that this code path imposes already quite a bit of overhead, overhead that delays execution noticeably and makes debugging less delightful than I'd like, I would much prefer to do it in the way that I proposed, where the extra time penalty is imposed _only_ in case the special handling is actually needed. Thanks, Johannes -------- Original Message -------- From: Corinna Vinschen <[email protected]> Sent: December 15, 2025 4:27:01 PM GMT+01:00 To: Johannes Schindelin <[email protected]>, Takashi Yano <[email protected]> Cc: [email protected], Cody Tapscott <[email protected]> Subject: Re: [PATCH 3/3] Cygwin: is_console_app(): handle app execution aliases Johannes, Takashi, On Dec 15 14:37, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin <[email protected]> > > In 0a9ee3ea23 (Allow executing Windows Store's "app execution aliases", > 2021-03-12), I introduced support for calling Microsoft Store > applications. > > However, it was reported several times (first in > https://inbox.sourceware.org/cygwin/CAAM_cieBo_M76sqZMGgF+tXxswvT=juhl_pshff+arv9p1e...@mail.gmail.com > and then also in > https://github.com/msys2/MSYS2-packages/issues/1943#issuecomment-3467583078) > that there is something amiss: The standard handles are not working as > expected, as they are not connected to the terminal at all (and hence > the application seems to "hang"). > > The culprit is the `is_console_app()` function which assumes that it can > simply open the first few bytes of the `.exe` file to read the PE header > in order to determine whether it is a console application or not. > > For app execution aliases, already creating a regular file handle for > reading will fail. Let's introduce some special handling for the exact > error code returned in those instances, and try to read the symlink > target instead (taking advantage of the code I introduced in 0631c6644e > (Cygwin: Treat Windows Store's "app execution aliases" as symbolic > links, 2021-03-22) to treat app execution aliases like symbolic links). > > Signed-off-by: Johannes Schindelin <[email protected]> > --- > winsup/cygwin/fhandler/termios.cc | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/winsup/cygwin/fhandler/termios.cc > b/winsup/cygwin/fhandler/termios.cc > index 5505bf416..6edd5be9b 100644 > --- a/winsup/cygwin/fhandler/termios.cc > +++ b/winsup/cygwin/fhandler/termios.cc > @@ -710,6 +710,19 @@ is_console_app (const WCHAR *filename) > HANDLE h; > h = CreateFileW (filename, GENERIC_READ, FILE_SHARE_READ, > NULL, OPEN_EXISTING, 0, NULL); > + if (h == INVALID_HANDLE_VALUE && GetLastError () == ERROR_CANT_ACCESS_FILE) > + { > + UNICODE_STRING ustr; > + RtlInitUnicodeString (&ustr, filename); > + path_conv pc (&ustr, PC_SYM_FOLLOW); > + if (!pc.error && pc.exists ()) > + { > + tmp_pathbuf tp; > + PWCHAR path = tp.w_get (); > + h = CreateFileW (pc.get_wide_win32_path (path), GENERIC_READ, > + FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); > + } > + } > if (h == INVALID_HANDLE_VALUE) > return false; > char buf[1024]; Erm... does this patch collide with https://sourceware.org/pipermail/cygwin-patches/2025q4/014421.html by any chance? Are you both trying to fix the same problem somehow? Thanks, Corinna
