"James Youngman" <[EMAIL PROTECTED]> 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.
