Date: Sat, 15 Jan 2005 16:25:44 -0500 From: David Schultz <das@FreeBSD.ORG> To: Tim Kientzle <kientzle@FreeBSD.ORG> Cc: Pawel Jakub Dawidek <pjd@FreeBSD.ORG> Subject: Re: fts improvements, alternatives Message-ID: <20050115212544.GA13274@VARK.MIT.EDU> In-Reply-To: <41E776DA.6080809@freebsd.org> References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> <41E716F3.20504@freebsd.org> <20050114064806.GA10856@VARK.MIT.EDU> <41E776DA.6080809@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050115212544.GA13274>