From owner-freebsd-doc@FreeBSD.ORG Sat Mar 17 15:20:13 2012 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E593106564A for ; Sat, 17 Mar 2012 15:20:13 +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 D35158FC2A for ; Sat, 17 Mar 2012 15:20:10 +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 q2HFKARu024971 for ; Sat, 17 Mar 2012 15:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2HFKAIZ024970; Sat, 17 Mar 2012 15:20:10 GMT (envelope-from gnats) Date: Sat, 17 Mar 2012 15:20:10 GMT Message-Id: <201203171520.q2HFKAIZ024970@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Jilles Tjoelker 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: Jilles Tjoelker List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 15:20:13 -0000 The following reply was made to PR docs/166091; it has been noted by GNATS. From: Jilles Tjoelker To: Matthew Story 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 16:11:03 +0100 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. > > 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) > 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). -- Jilles Tjoelker