From owner-freebsd-doc@FreeBSD.ORG Sat Mar 17 16:10:15 2012 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B13C0106568A for ; Sat, 17 Mar 2012 16:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC468FC16 for ; Sat, 17 Mar 2012 16:10:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2HGAF78070125 for ; Sat, 17 Mar 2012 16:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2HGAFYT070124; Sat, 17 Mar 2012 16:10:15 GMT (envelope-from gnats) Date: Sat, 17 Mar 2012 16:10:15 GMT Message-Id: <201203171610.q2HGAFYT070124@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Matthew Story Cc: Subject: Re: docs/166091: [libc][patch] fts(3) should document cases where FTS_NOCHDIR option is set as a side-effect X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Story List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 16:10:15 -0000 The following reply was made to PR docs/166091; it has been noted by GNATS. From: Matthew Story To: Jilles Tjoelker 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 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 > 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 <jilles@stack.nl> wrote:
On Fri, Mar 16, 2012 at 07:02:47PM -0400, Matthew Story w= rote:
> 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 b= e
> > relied on.

> I agree with this, but as the behavior is non-obvious I think it shoul= d be
> noted. =A0Perhaps this is more appropriate for the BUGS section than t= he
> fts_open section?

Yes.

Updated patch (attached) to = document the side-effect cases in BUGS section, available via http here:

=A0

> > If FTS_NOCHDIR is set, fts(3) runs slower and is subject to
> > {PATH_MAX}. The latter would violate POSIX in various utilities.<= br>
> 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 fai= l if an argument sent already exceeds PATH_MAX, understood.
=A0
> I tried to allow FTS_LOGICAL without FTS_NOCHDIR a while ago, but whil= e
> > 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 add= ed (for now,
> > O_EXEC works) so it only needs 'x' right not also 'r&= #39;.

> So this would then fall back to FTS_NOCHDIR if `.' is not searchab= le?

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).

=A0

--
Jilles Tjoelker=A0



--
regards,
matt
--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--