Date: Sat, 17 Mar 2012 16:10:15 GMT From: Matthew Story <matthewstory@gmail.com> To: freebsd-doc@FreeBSD.org Subject: Re: docs/166091: [libc][patch] fts(3) should document cases where FTS_NOCHDIR option is set as a side-effect Message-ID: <201203171610.q2HGAFYT070124@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/166091; it has been noted by GNATS. From: Matthew Story <matthewstory@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: bug-followup@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@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@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@stack.nl">jilles@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@stack.nl">jilles@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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203171610.q2HGAFYT070124>