Although I know very little about fts itself, I have all the pre-requisites to be able to debug the problem in fts on Solaris, except for time. I already have a number of free-software mini-projects that are on the back-burner for lack of time to hack on them.
Martin >>>>> "J" == James Youngman <[EMAIL PROTECTED]> writes: J> On Feb 20, 2008 12:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: >> This reminds me of the long-planned fork, e.g., s/fts_*/gfts_*/, >> (all public symbols) in which I create new files named gfts.[ch]. Then, >> someday, I can propose adding it to glibc. Remember, proposing the >> addition with new names is the only way to add the improved functions >> to glibc, due to the API changes that make the gnulib version more robust. J> I'm looking forward to collaborating on that. >> A couple months ago I finally did most of the work, and have adapted >> coreutils to use the new names (still all private for the moment). >> Just need to find time to write ChangeLog entries, etc. and decide how >> to handle maintenance of the resulting duplication. I'm leaning toward >> deriving gfts.c mechanically, at least initially, but that's messy. >> There are many exceptions, and evaluating that takes time, too. J> I should point out that Martin has been finding that the fts-based J> find exhibits different behaviour to the non-fts find on file systems J> with a Sun Solaris automounter. We don't yet have details of what, in J> particular, is different about what the fts based version is doing. J> However, he noted that --disable-leaf-optimisation doesn't have any J> effect on the fts-based find executable. Details (and a patch which J> appears actually to not solve the problem, somewhat to my surprise) at J> http://savannah.gnu.org/bugs/?22301. J> Thanks, J> James.
