On Jul 22 21:32, Takashi Yano wrote: > Previously, process_fd did not handle fhandler using archetype > correctly. Due to lack of PC_OPEN flag for path_conv, build_fh_pc() > could not initialize archetype. Because of this bug, accessing pty > or console via process_fd fails. > > With this patch, use build_fh_name() with PC_OPEN flag instead of > build_fh_pc() to set PC_OPEN flag to path_conv.
Your patch fixes the issue, ok, but I don't understand why this occurs. If the process opens /proc/PID/fd/N with PID != MYPID, it uses the PICOM_FILE_PATHCONV commune request. It copies the path_conv member of the fd from the target process and this pc is used in the build_fh_pc() call. And here's what I don't get: If the pc has been fetched from a valid, open file descriptor in the target process, why is the PATH_OPEN flag not set? Thanks, Corinna > > Addresses: https://cygwin.com/pipermail/cygwin/2025-May/258167.html > Fixes: 7aca27b4fe55 ("Cygwin: introduce fhandler_process_fd and add stat(2) > handling") > Reported-by: Christian Franke <[email protected]> > Reviewed-by: > Signed-off-by: Takashi Yano <[email protected]> > --- > winsup/cygwin/fhandler/process_fd.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/winsup/cygwin/fhandler/process_fd.cc > b/winsup/cygwin/fhandler/process_fd.cc > index d81495103..14ae8746a 100644 > --- a/winsup/cygwin/fhandler/process_fd.cc > +++ b/winsup/cygwin/fhandler/process_fd.cc > @@ -97,7 +97,7 @@ fhandler_process_fd::fetch_fh (HANDLE &out_hdl, uint32_t > flags) > pc.get_posix ()); > pc.set_posix (fullpath); > } > - fhandler_base *fh = build_fh_pc (pc); > + fhandler_base *fh = build_fh_name (pc.get_posix (), PC_OPEN); > if (!fh) > { > CloseHandle (hdl); > -- > 2.45.1
