Re: Why does -inum require stat(2)?

[George Spelvin]

"James Youngman" <address@hidden> 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.