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