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

[Jim Meyering]

Ian Jackson <address@hidden> wrote:

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

The same issues are discussed in that thread.

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

Yes, but only on a system where readdir- and lstat-reported inode
numbers differ.

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

I think correctness is important enough to sacrifice
the optimization in this unusual corner-case usage of ls.
(how often do you use ls -i?  of those times, how often
are there enough implicitly-listed files that you would
notice a longer run time?)

I consider the stat-reported inode numbers to be authoritative.
That ls -i prints other numbers _as a result of an optimization_
feels disconcertingly like a bug.

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

Perhaps no program relies on 'ls -i'-reported inode numbers
(for implicitly-listed files) matching those reported by stat.
Not unlikely.  But this is a subtle enough issue that I can
imagine it causing trouble some day.

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

I've run experiments on Solaris 10 and FreeBSD 6, and see that they
exhibit the same undesirable behavior, so this is not Linux-specific.

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

Why?  and more importantly,
Why should performance trump correctness?
Do you know of an application that uses ls -i and requires
the performance of the stat-avoiding optimization?
Even if there does exist such an application, I question whether
it is worth making it faster at the expense of correctness.

> It always used to be.

No, GNU ls has not always used this optimization.
It appeared first in coreutils-6.0.
Before then, ls would call lstat for each entry.