docs/166091: [libc][patch] fts(3) should document cases where FTS_NOCHDIR option is set as a side-effect
Matthew Story
matthewstory at gmail.com
Sat Mar 17 16:10:15 UTC 2012
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: Sat, 17 Mar 2012 12:07:38 -0400
--14dae9cdc1072cb56904bb728610
Content-Type: multipart/alternative; boundary=14dae9cdc1072cb56204bb72860e
--14dae9cdc1072cb56204bb72860e
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Mar 17, 2012 at 11:11 AM, Jilles Tjoelker <jilles at stack.nl> wrote:
> On Fri, Mar 16, 2012 at 07:02:47PM -0400, Matthew Story wrote:
> > 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?
>
> Yes.
>
Updated patch (attached) to document the side-effect cases in BUGS section,
available via http here:
http://axe0.blackskyresearch.net/patches/matt/fts.3.add_FTS_NOCHDIR_side_effect_cases.patch.txt
>
> > > 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?
>
> Yes. The POSIX page about find is pretty clear on this issue:
>
> % The find utility shall be able to descend to arbitrary depths in a
> % file hierarchy and shall not fail due to path length limitations
> % (unless a path operand specified by the application exceeds {PATH_MAX}
> % requirements)
>
so find should only fail if an argument sent already exceeds PATH_MAX,
understood.
> > 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?
>
> No. My patch (from over a year ago) is at
> http://www.stack.nl/~jilles/unix/fts-logical-chdir-2.patch but I forgot
> what severe breakage it causes.
>
> > > 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?
>
> Yes. This could be avoided by using functions like openat(2) and
> fstatat(2) instead of changing the current directory, but only by
> changing the API (because the current API requires fts(3) to furnish a
> pathname that will access the object, not an fd and a pathname relative
> to it).
>
couldn't this be accommodated by internally maintaining an fd to each path?
Alternatively, adding an fts_openat function would allow for this
behavior, without modifying the imprint of fts_open.
>
> --
> Jilles Tjoelker
--
regards,
matt
--14dae9cdc1072cb56204bb72860e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sat, Mar 17, 2012 at 11:11 AM, Jilles Tjoelker <span dir=3D"ltr"><<a =
href=3D"mailto:jilles at stack.nl">jilles at stack.nl</a>></span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Fri, Mar 16, 2012 at 07:02:47PM -0400, Matthew Story w=
rote:<br>
> On Fri, Mar 16, 2012 at 6:38 PM, Jilles Tjoelker <<a href=3D"mailto=
:jilles at stack.nl">jilles at stack.nl</a>> wrote:<br>
<br>
> > > [fts(3) automatically sets FTS_NOCHDIR option in some cases]=
<br>
<br>
> > I consider the automatic FTS_NOCHDIR a semi-bug that should not b=
e<br>
> > relied on.<br>
<br>
> I agree with this, but as the behavior is non-obvious I think it shoul=
d be<br>
> noted. =A0Perhaps this is more appropriate for the BUGS section than t=
he<br>
> fts_open section?<br>
<br>
</div>Yes.<br></blockquote><div><br></div><div>Updated patch (attached) to =
document the side-effect cases in BUGS section, available via http here:</d=
iv><div><br></div><div><a href=3D"http://axe0.blackskyresearch.net/patches/=
matt/fts.3.add_FTS_NOCHDIR_side_effect_cases.patch.txt">http://axe0.blacksk=
yresearch.net/patches/matt/fts.3.add_FTS_NOCHDIR_side_effect_cases.patch.tx=
t</a><br>
</div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
> > If FTS_NOCHDIR is set, fts(3) runs slower and is subject to<br>
> > {PATH_MAX}. The latter would violate POSIX in various utilities.<=
br>
<br>
> this would mean that find -L is currently in violation of POSIX?<br>
<br>
</div>Yes. The POSIX page about find is pretty clear on this issue:<br>
<br>
% The find utility shall be able to descend to arbitrary depths in a<br>
% file hierarchy and shall not fail due to path length limitations<br>
% (unless a path operand specified by the application exceeds {PATH_MAX}<br=
>
% requirements)<br></blockquote><div><br></div><div>so find should only fai=
l if an argument sent already exceeds PATH_MAX, understood.</div><div>=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div class=3D"im">
> I tried to allow FTS_LOGICAL without FTS_NOCHDIR a while ago, but whil=
e<br>
> > it is conceptually possible, actually making it work is hard.<br>
<br>
> Is anyone currently looking into this?<br>
<br>
</div>No. My patch (from over a year ago) is at<br>
<a href=3D"http://www.stack.nl/~jilles/unix/fts-logical-chdir-2.patch" targ=
et=3D"_blank">http://www.stack.nl/~jilles/unix/fts-logical-chdir-2.patch</a=
> but I forgot<br>
what severe breakage it causes.<br>
<div class=3D"im"><br>
> > The open(".", O_RDONLY) can use O_SEARCH when it is add=
ed (for now,<br>
> > O_EXEC works) so it only needs 'x' right not also 'r&=
#39;.<br>
<br>
> So this would then fall back to FTS_NOCHDIR if `.' is not searchab=
le?<br>
<br>
</div>Yes. This could be avoided by using functions like openat(2) and<br>
fstatat(2) instead of changing the current directory, but only by<br>
changing the API (because the current API requires fts(3) to furnish a<br>
pathname that will access the object, not an fd and a pathname relative<br>
to it).<br></blockquote><div><br></div><div>couldn't this be accommodat=
ed by internally maintaining an fd to each path? =A0Alternatively, adding a=
n fts_openat function would allow for this behavior, without modifying the =
imprint of fts_open.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Jilles Tjoelker</font></span>=A0</blockquote></div><br><br clear=3D"all"><d=
iv><br></div>-- <br>regards,<br>matt<br>
--14dae9cdc1072cb56204bb72860e--
--14dae9cdc1072cb56904bb728610
Content-Type: text/plain; charset=US-ASCII;
name="fts.3.add_FTS_NOCHDIR_side_effect_cases.patch.txt"
Content-Disposition: attachment;
filename="fts.3.add_FTS_NOCHDIR_side_effect_cases.patch.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gzwujk9t0
SW5kZXg6IGZ0cy4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGZ0cy4zCShyZXZpc2lvbiAyMzMwODkpCisrKyBm
dHMuMwkod29ya2luZyBjb3B5KQpAQCAtNzk4LDMgKzc5OCwxMyBAQAogcHJpbmNpcGFsbHkgdG8g
cHJvdmlkZSBmb3IgYWx0ZXJuYXRpdmUgaW50ZXJmYWNlcyB0byB0aGUKIC5ObQogZnVuY3Rpb25h
bGl0eSB1c2luZyBkaWZmZXJlbnQgZGF0YSBzdHJ1Y3R1cmVzLgorLlNoIEJVR1MKK1RoZSAKKy5G
biBmdHNfb3BlbgorZnVuY3Rpb24gd2lsbCBhdXRvbWF0aWNhbGx5IHNldCB0aGUKKy5EdiBGVFNf
Tk9DSERJUgorb3B0aW9uIGlmIHRoZSAKKy5EdiBGVFNfTE9HSUNBTAorb3B0aW9uIGlzIHByb3Zp
ZGVkLCBvciBpZiBpdCBjYW5ub3QgCisuWHIgb3BlbiAyCisuUWwgLlwmIC4K
--14dae9cdc1072cb56904bb728610--
More information about the freebsd-doc
mailing list