"George Spelvin" <[EMAIL PROTECTED]> wrote: > "James Youngman" <[EMAIL PROTECTED]> wrote: >> This is something that find has needed for quite a while. There is a >> somewhat more general problem too - the ftsfind program itself seems >> to stat files that fts() already stated, I think. >> >> There may also be other opportunities for improvement, too. For >> example I have read that sorting your list of filenames by inode >> number can significantly reduce the amount of head movement needed to >> stat all the files in a directory. But I don't know for sure if that >> is still true with modern filesystems. > > With UFS/ext2-like file systems, it does help, because inode number > determines the physical inode placement. For some more advanced ones, > I'm not sure. > > I've also considered having worker threads to multi-thread the stat() calls. > >>> And if you'll tell me how to do it, I'll do it as a work for hire for >>> you and you can assign it to the EFF. (17 USC 101: "Works Made for >>> Hire [...] (2) a work specially ordered or commissioned for use as a >>> contribution to a collective work [...] if the parties expressly agree >>> in a written instrument signed by them that the work shall be considered >>> a work made for hire.") >> >> Great. That is the common practice at GNU (we call the written >> instrument a "copyright assignment"). > > I know, but the FSF paperwork is time-consuming, so I proposed to > keep everyone happy by doing it as work for hire for you, thus it's > born copyrighted to you, and you can use your existing FSF paperwork to > assign it to the FSF. > > Anyway, I'll have a look at the fts code and see what can be done. > I'll need to add an fts_ino field, at least.
Some inode-related support is going in soon (like in the next day or two), so you might want to wait. It uses the existing fts_stat.st_ino field.
