[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fts in gnulib behave different than glibc

From: Jim Meyering
Subject: Re: fts in gnulib behave different than glibc
Date: Wed, 28 Jul 2021 22:42:53 -0700

On Wed, Jul 28, 2021 at 1:08 AM Simon Josefsson via Gnulib discussion
list <bug-gnulib@gnu.org> wrote:
> Hi.  I replaced GNU InetUtils' old custom fts implementation with the
> one from gnulib, but self-tests started failing.  Looking at the code,
> it seems gnulib's fts implementation has diverged compared to glibc, and
> has some optimizations that (I think) change the API (wrt stat and
> chdir).  Also, gnulib's fts module is always enabled, even on modern
> glibc systems.  InetUtils's usage of fts works fine with modern glibc,
> but it didn't work with gnulib's version (it needed a FTS_NOCHDIR).  The
> gnulib manual for the fts replacement module isn't terribly clear about
> this.  Is there a reason for this behaviour?
> I would prefer if there were two fts modules in gnulib:
> 1) One module 'fts' based on glibc's code, that is only enabled in on
> systems that doesn't have fts, or where fts is known to be buggy.
> 2) One 'fts-faster' that is the current code, which can be used when you
> always wants to pull in the optimized implementation.
> Then InetUtils would use system fts on glibc platforms, and not always
> have to pull in a replacement copy.
> What do you think?
> I could live with a new module 'fts-optional' that only pulls in the
> current 'fts' module when the system is lacking it.  That doesn't fix
> the API confusion, but is probably sufficient for InetUtils.

There are fundamental flaws in the ABI of glibc's fts that make it
unsuitable for use in any tool I care about.
Those flaws make it easy to hit silly limits or to provoke inordinate
resource usage/DoS.
Is it ok for InetUtil's fts to be unable to do these things? (each of
which afflicts glibc fts, from what I recall)
- process files in a tree more than 2^16 levels deep
- detect certain cycles efficiently
- delete (in reasonable time) a hierarchy with too many entries in a
single directory.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]