On Jul 24 11:17, Takashi Yano wrote:
> On Thu, 24 Jul 2025 09:10:16 +0900
> Takashi Yano wrote:
> > On Wed, 23 Jul 2025 14:53:33 +0200
> > Corinna Vinschen wrote:
> > > 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
Ah, right, thank you. That's what I missed. I only saw the
fh->set_name() calls but missed the fact that some of them are not using
the variation taking a path_conv argument. D'oh.
> 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 ();
I think it's basically the right thing to do, but like this?
if (pc->isopen())
fh->pc.set_isopen ();
?
Thanks,
Corinna
