Re: making GNU ls -i (--inode) work around the linux readdir bug

[Paul Eggert]

Tony Finch <address@hidden> writes:

> Also, readdir(3) is not the only part of POSIX that needs clarifying.

I participated in the discussion that resulted in this new d_ino
wording being added to POSIX, and my recollection is that the common
behavior where readdir returns the inode number of the underlying
mount point is now considered to be a bug, both for readdir purposes
and for ls -i purposes (as well as for find -inum purposes).  That is,
these functions are now all supposed to use the inode number of the
root of the mounted file system, and this is supposed to be the same
number for all purposes; and the underlying mount point's inode number
is supposed to be inaccessible via the standard interfaces.

If there's any further question about this it might help to track down
the relevant Austin Group discussion.

Oould argue that this is really a readdir bug, not an ls -i bug, and
that (pragmatically, for efficiency reasons) it may be better for the
GNU "ls" maintainer to punt and tell users to get a working kernel.
On the other hand, there is a long tradition of GNU tools working
around bugs in the underlying operating systems.

I don't think this is a slam-dunk decision either way.  Still, given
the arguments I've seen so far I'd favor having coreutils work around
the bug unless the performance penalty is really, really bad.