On Tue, 5 Mar 2024 11:14:46 +0100 Corinna Vinschen wrote: > 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. I'll submit v3 patch. Please review. > 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. Is the patch attached as you intended? -- Takashi Yano