Date: Fri, 26 Apr 2013 16:17:27 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Joshua Isom <jrisom@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Some improvements to rm(1) Message-ID: <20130426141726.GA85955@stack.nl> In-Reply-To: <517A8242.6090509@gmail.com> References: <CAF6rxg=5aAyk88KcbuGhG1Nwn5HdYqMiaT7umX2EOLApDwOk4Q@mail.gmail.com> <20130426025049.GC50623@lor.one-eyed-alien.net> <CAF6rxgm6J63M7JO4%2BxqwPNu1KwTrmEiOK5YKT5hYXb5yEag0Zg@mail.gmail.com> <20130426122214.GA9086@stack.nl> <CAF6rxgnyOizqdkkG2q17z6uk7=tLyO6WqyzzE-xsgd_Q2a8Gbw@mail.gmail.com> <517A8242.6090509@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 26, 2013 at 08:33:54AM -0500, Joshua Isom wrote:
> On 4/26/2013 7:23 AM, Eitan Adler wrote:
> > Yes, rm's functionality can be fully replicated by find.
> As well as anything using -R.
Emulating other -R things using find becomes quite slow when you don't
want to impose {PATH_MAX} limits or open up symlink-based race windows
because the only safe option is -execdir UTILITY {} \;. Any find command
based on -exec, -print or -print0 passes pathnames which are subject to
{PATH_MAX} limits and directories concurrently replaced with symlinks.
The construct -execdir ... {} + is unusably broken in older FreeBSD
versions and gives no advantage compared to -execdir ... {} \; in recent
-CURRENT.
With -L, this is not a new problem because symlinks are followed anyway
and the underlying code (fts(3)) always imposes the {PATH_MAX} limit in
that case.
The -delete primary is safe like -execdir.
I'm not entirely sure about this because the rm(1) patch is simple and
the new syntax is fairly clear.
--
Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130426141726.GA85955>