Date: Thu, 13 Jan 2005 23:38:02 -0800 From: Tim Kientzle <kientzle@freebsd.org> To: David Schultz <das@freebsd.org> Cc: Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: fts improvements, alternatives Message-ID: <41E776DA.6080809@freebsd.org> In-Reply-To: <20050114064806.GA10856@VARK.MIT.EDU> References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> <41E716F3.20504@freebsd.org> <20050114064806.GA10856@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Accepting a sort parameter is probably not in the making, of course. Part of the whole point to "tree" is that it doesn't store a lot of data at one time. fts has to be better at something, right? ;-) Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41E776DA.6080809>