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.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
