Date: Sat, 17 Mar 2012 15:20:10 GMT From: Jilles Tjoelker <jilles@stack.nl> 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: <201203171520.q2HFKAIZ024970@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: Jilles Tjoelker <jilles@stack.nl>
To: Matthew Story <matthewstory@gmail.com>
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 <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.
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203171520.q2HFKAIZ024970>