Re: fts improvements, alternatives

On Thu, Jan 13, 2005, Tim Kientzle wrote:
> David Schultz wrote:
> >On Thu, Jan 13, 2005, Tim Kientzle wrote:
> >>
> >>As it happens, I started tinkering with these ideas 
> >>[about a better way to traverse directory trees] a
> >>while ago but haven't found time to finish it all.
> >>
> >>Here's a snapshot of the current WIP:
> >>
> >>http://people.freebsd.org/~kientzle/libarchive/src/tree.tgz
> >
> >Nice.  That's much cleaner than the fts implementation (although
> >it doesn't do all that fts does.)  So tell me again: when did you
> >say were you planning on rewriting/fixing fts?  ;-)
> 
> The basic problems with fts are hard to fix
> without breaking the API badly.  On the other
> hand, augmenting "tree" to the point that it can
> replace fts in many (but not all) applications
> would interest me.
> 
> Since you've done more work with fts-using applications
> than I have recently, you tell me:  What does
> "tree" absolutely require to be usable in a broad
> cross-section of applications?  It already does
> what bsdtar needs, of course.

I don't have experience with a ``broad cross-section'' of
fts-using applications, but support for physical and logical
traversals, not crossing a mount point, and the ability to choose
whether to stat files or not, seem frequently used.  Your library
seems to have no problem with these, except that it calls stat(2)
on every entry.  For UFS, not calling stat(2) is an important
optimization because it means only reading the (usually
contiguous) contents of the directory rather than seeking to all
the inodes for the files.  I believe getdirentries(2) makes it
possible to identify the type of a file without reading its inode,
although the readdir(3) interface hides that information, forcing
fts(3) to perform some acrobatics to infer that information.

Given that your tree library doesn't suffer some of the
limitations of fts, I think it would be a great addition to
FreeBSD.  Even better would be to reimplement fts and ftw as
wrappers for it, if you think it would be reasonable to do so. ;-)