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

[Ian Jackson]

Jim Meyering writes ("making GNU ls -i (--inode) work around the linux readdir 
bug"):
> With a Linux-based kernel, GNU ls -i can list the wrong inode
> for a mount point.
> 
> Ian Jackson raised this issue two years ago with
> http://bugs.debian.org/369822, and Wayne Pollock reported it
> last week via http://bugzilla.redhat.com/453709

This is not the issue I am complaining about.  What I was complaining
about is that   ls -i  was very slow because the optimisation had
been disabled.

That is to say you are proposing to fix my complaint by entrenching
the thing I was complaining about.

> The plan is to test each non-root mount point at configure time by
> running a C program that calls readdir and lstat and compares the
> resulting inode numbers.  If they ever mismatch, or the test fails
> for any other reason, disable the "optimization" whereby ls.c relies
> on readdir's POSIX-specified d_ino value rather than calling "lstat"
> for each directory entry.  Note that this applies only to "implicit"
> arguments, i.e., not to names listed on the ls command-line.

I think this is quite wrong.  You should never disable this
optimisation.

Note that since ls -i does not print device numbers, the output is not
really meaningful near mountpoints, since inode numbers are only
unique within a device.

All systems have traditionally behaved the way I want: that is, to
return the inode number of the underlying masked mountpoint
directory.

Really, I don't care what number is returned and neither should anyone
else.  Are there _any_ even arguably correct programs which depend on
the inode number there being `right' ?  What I care about is that
ls -i  should be as fast as readdir.  It always used to be.

Ian.