Re: making fts thread-safe (no more fchdir)

[Jim Meyering]

address@hidden (James Youngman) wrote:
> On Tue, Jan 17, 2006 at 10:33:18PM +0100, Jim Meyering wrote:
>> FTS API change:
>> ==============
>>
>> This changes the fts API.
>
> Is there a way for autoconf-using gnulib client s to select only the
> gnulib version?  I'm happy to adopt the change, as long as I don;t run
> the risk of having 'configure' wrongly select the wrong fts()
> implementation.

Hi Jay,

There's no need to worry, since the gnulib fts module uses lib/fts.c and
fts_.h exclusively.  I made it do that from the start, because some of
the first changes I made were to the ABI.

Some of the glibc and NetBSD problems that come to mind:

  - inappropriate member types in fts.h, e.g., `short fts_pathlen'
      This usually limits the max file name length to be 32K.
      In gnulib, the type is size_t.

  - cycle detection while traversing an N-level tree takes O(N**2) time
      This makes fts take forever for a deep (say, 50K-level) hierarchy.
      With gnulib's fts, it takes only O(N) time -- a big difference.
      Implementing this meant adding a new struct member or two.