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

[Jim Meyering]

"George Spelvin" <address@hidden> wrote:
> "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.

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.