On Thu, 24 Jul 2025 09:10:16 +0900
Takashi Yano wrote:
> On Wed, 23 Jul 2025 14:53:33 +0200
> Corinna Vinschen wrote:
> > On Jul 23 19:55, Takashi Yano wrote:
> > > On Wed, 23 Jul 2025 11:04:02 +0200
> > > Corinna Vinschen wrote:
> > > > 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 for reviewing.
> > >
> > > I looked into open process, and noticed that this is because fh_alloc()
> > > called from build_fh_name() does not copy argument pc.path_flags to
> > > fh->pc.path_flags.
> >
> > No, wait. build_fh_name() creates a path_conv instance and that in turn
> > is used to call build_fh_pc(). build_fh_pc() calls fh_alloc() and then
> > calls fh->set_name (pc) in allmost all scenarios. This in turn should
> > copy pc.path_flags, because the underlying path_conv::<< operator is
> > basically a memcpy().
>
> In the case use_archetype() is true, fh->set_name(pc) does not seem
> to be called.
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/dtable.cc;h=f1832a1693d45d5fd1e27acb830d5a12a6a34238;hb=HEAD#l683
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/dtable.cc;h=f1832a1693d45d5fd1e27acb830d5a12a6a34238;hb=HEAD#l676
So, the following patch also fixes the issue.
diff --git a/winsup/cygwin/dtable.cc b/winsup/cygwin/dtable.cc
index f1832a169..3b25e9160 100644
--- a/winsup/cygwin/dtable.cc
+++ b/winsup/cygwin/dtable.cc
@@ -674,6 +674,7 @@ build_fh_pc (path_conv& pc)
fh->archetype->get_handle ());
if (!fh->get_name ())
fh->set_name (fh->archetype->dev ().name ());
+ fh->pc.set_isopen ();
}
else if (cygwin_finished_initializing && !pc.isopen ())
fh->set_name (pc);
@@ -681,6 +682,7 @@ build_fh_pc (path_conv& pc)
{
if (!fh->get_name ())
fh->set_name (fh->dev ().native ());
+ fh->pc.set_isopen ();
fh->archetype = fh->clone ();
debug_printf ("created an archetype (%p) for %s(%d/%d)", fh->archetype,
fh->get_name (), fh->dev ().get_major (), fh->dev ().get_minor ());
fh->archetype->archetype = NULL;
diff --git a/winsup/cygwin/local_includes/path.h
b/winsup/cygwin/local_includes/path.h
index 1fd542c96..9f62fd993 100644
--- a/winsup/cygwin/local_includes/path.h
+++ b/winsup/cygwin/local_includes/path.h
@@ -258,6 +258,10 @@ class path_conv
else
mount_flags &= ~MOUNT_CYGWIN_EXEC;
}
+ void set_isopen ()
+ {
+ path_flags |= PATH_OPEN;
+ }
bool isro () const {return !!(mount_flags & MOUNT_RO);}
bool exists () const {return fileattr != INVALID_FILE_ATTRIBUTES;}
bool has_attribute (DWORD x) const {return exists () && (fileattr & x);}
--
Takashi Yano <[email protected]>
