docs/166091: [libc][patch] fts(3) should document cases where FTS_NOCHDIR option is set as a side-effect

[Matthew Story]

The following reply was made to PR docs/166091; it has been noted by GNATS.

From: Matthew Story <matthewstory at gmail.com>
To: Jilles Tjoelker <jilles at stack.nl>
Cc: bug-followup at freebsd.org
Subject: Re: docs/166091: [libc][patch] fts(3) should document cases where
 FTS_NOCHDIR option is set as a side-effect
Date: Fri, 16 Mar 2012 19:02:47 -0400

 --20cf3071cf260a2e7f04bb64357f
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Fri, Mar 16, 2012 at 6:38 PM, Jilles Tjoelker <jilles at stack.nl> wrote:
 
 > > [fts(3) automatically sets FTS_NOCHDIR option in some cases]
 >
 > I consider the automatic FTS_NOCHDIR a semi-bug that should not be
 > relied on.
 
 
 I agree with this, but as the behavior is non-obvious I think it should be
 noted.  Perhaps this is more appropriate for the BUGS section than the
 fts_open section?
 
 
 > If FTS_NOCHDIR is set, fts(3) runs slower and is subject to
 > {PATH_MAX}. The latter would violate POSIX in various utilities.
 >
 
 this would mean that find -L is currently in violation of POSIX?
 
 I tried to allow FTS_LOGICAL without FTS_NOCHDIR a while ago, but while
 > it is conceptually possible, actually making it work is hard.
 >
 
 Is anyone currently looking into this?
 
 
 >
 > The open(".", O_RDONLY) can use O_SEARCH when it is added (for now,
 > O_EXEC works) so it only needs 'x' right not also 'r'.
 >
 
 So this would then fall back to FTS_NOCHDIR if `.' is not searchable?
 
 
 >
 > --
 > Jilles Tjoelker
 >
 
 
 
 -- 
 regards,
 matt
 
 --20cf3071cf260a2e7f04bb64357f
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Mar 16, 2012 at 6:38 PM, Jilles Tjoelker <span dir=3D"ltr"><<a h=
 ref=3D"mailto:jilles at stack.nl">jilles at stack.nl</a>></span> wrote:<br><di=
 v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 > [fts(3) automatically sets FTS_NOCHDIR option in some cases]<br>
 <br>
 I consider the automatic FTS_NOCHDIR a semi-bug that should not be<br>
 relied on.</blockquote><div><br></div><div>I agree with this, but as the be=
 havior is non-obvious I think it should be noted. =A0Perhaps this is more a=
 ppropriate for the BUGS section than the fts_open section?</div><div>=A0</d=
 iv>
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex"> If FTS_NOCHDIR is set, fts(3) runs slower a=
 nd is subject to<br>
 {PATH_MAX}. The latter would violate POSIX in various utilities.<br></block=
 quote><div><br></div><div>this would mean that find -L is currently in viol=
 ation of POSIX?</div><div><br></div><blockquote class=3D"gmail_quote" style=
 =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 
 I tried to allow FTS_LOGICAL without FTS_NOCHDIR a while ago, but while<br>
 it is conceptually possible, actually making it work is hard.<br></blockquo=
 te><div><br></div><div>Is anyone currently looking into this?</div><div>=A0=
 </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
 eft:1px #ccc solid;padding-left:1ex">
 
 <br>
 The open(".", O_RDONLY) can use O_SEARCH when it is added (for no=
 w,<br>
 O_EXEC works) so it only needs 'x' right not also 'r'.<br><=
 /blockquote><div><br></div><div>So this would then fall back to FTS_NOCHDIR=
  if `.' is not searchable?=A0</div><div>=A0</div><blockquote class=3D"g=
 mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
 eft:1ex">
 
 <span class=3D"HOEnZb"><font color=3D"#888888"><br>
 --<br>
 Jilles Tjoelker<br>
 </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
 r>regards,<br>matt<br>
 
 --20cf3071cf260a2e7f04bb64357f--