Re: [PATCH] Cygwin: pipe: Give up to use query_hdl for non-cygwin apps.

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Mar  5 09:06, Takashi Yano wrote:
> On Mon, 4 Mar 2024 18:38:07 +0100
> Corinna Vinschen wrote:
> > On Mar  4 16:45, ASSI wrote:
> > > Corinna Vinschen writes:
> > > > Right you are.  We always said that independent Cygwin installations
> > > > are supposed to *stay* independent.
> > > >
> > > > Keep in mind that they don't share the same shared objects in the native
> > > > NT namespace and they don't know of each other.  It's not only the
> > > > process table but also in-use FIFO stuff, pty info, etc.
> > > 
> > > What I was getting at is that a process not showing up in the process
> > > list in one Cygwin installation doesn't automatically mean it's a native
> > > Windows process, it could be a process started by an independent Cygwin
> > > installation.  So this way of checking for "native" Windows processes
> > > may or may not do what was originally intended.
> > 
> > But that was my point. A "foreign" Cygwin process from another
> > installation is not a Cygwin process.  Lots of interoperability
> > just won't work, so it's basically a native process.
> 
> Actually, I think query_hdl can be retrieved from the process
> from another installation of cygwin using NtQueryInformationProcess()
> with ProcessHandleInformation. However, I cannot imagne the case
> that the pipe is made by one cygwin installation but the reader
> process is from another installation of cygwin.
> 
> BTW, what about v2 patch itself?

It does the job with less code and less memory, which is good.
I would change the comment

  stop to try to get query_hdl for non-cygwin apps

to something like

  don't try to fetch query_hdl from non-cygwin apps

"stop trying" is a bit of a back-reference to the old code, which
is not necessary, I think.

This doesn't affect your patch, but while looking into this, what
strikes me as weird is that fhandler_pipe::temporary_query_hdl() calls
NtQueryObject() and assembles the pipe name via swscanf() every time it
is called.

Wouldn't it make sense to store the name in the fhandler's
path_conv::wide_path/uni_path at creation time instead?
The wide_path member is not used at all in pipes, ostensibly.


Thanks,
Corinna