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

[George Spelvin]

"James Youngman" <address@hidden> wrote:
> Based on what you write I would assume that this is true for both the
> find and the oldfind executables built in all even vaguely-recent
> findutils releases.

Er... I'm not familiar with the oldfind executable.  I'm using the
Debian-compiled amd64 4.4.0 binary.

> But in the case where the file we're currently considering is a
> non-directory, it can't also be a mount point.   Therefore where d_ino
> is available we should be able to trust it (famous last words :).
> Using stat only for directories is essentially zero cost, since we
> need to stat them as part of the traversal operations.

Yup.  I tested that Linux bind mounts (which can mount a file!)
alter d_ino.

Do you have any advice on extending the savedir code to include d_ino?
For a few days, I'm enthused about "scratching my itch" and can
dig into it, although I'd like some advice on making a "architectural"
change like that.

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.")

> So I guess this is a performance issue we can likely fix.   Could you
> add it as a findutils bug at savannah.gnu.org so that we don't forget
> it?
>
> (In practice changing find in this way may not fix the problem for the
> version of find that uses fts, so we may not get the full benefit of
> the fix, but I think changing this would at least be progress).
>
> Thanks for spotting the problem!
>
> James.