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

[Ian Jackson]

Jim Meyering writes ("Re: making GNU ls -i (--inode) work around the linux 
readdir bug"):
> Ian Jackson <address@hidden> wrote:
> > 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.

That is all systems.  All UN*X systems since the dawn of time have
behaved this way.

> I think correctness is important enough to sacrifice
> the optimization in this unusual corner-case usage of ls.

This is the whole _point_ of  ls -i  !

> (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?)

Nearly all of the invocations of  ls -i  on my systems are by
automated processes which do not list all of the arguments and which
depend on the optimisation.

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

I think you should get over this feeling.  It's not a bug.  It's the
permitted by the specs and it is the way  ls -i  has always behaved in
every system not using the (broken) coreutils behaviour.

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

Those programs are already broken on every system which doesn't use
GNU ls.

The kind of programs which uses  ls -i  is the kind which wants to
efficiently determine which files are the same as which other files.
Such programs depend on the knowledge that they aren't going to be
interfered with by mountpoints.  They also depend on the optimisation
for acceptable performance.

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

So behaviour you consider `undesirable' is in fact the standard.

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

It's only incorrect in situations where using the inode number is
incorrect anyway.  You've failed to respond to my comments about the
lack of the device number.

> Do you know of an application that uses ls -i and requires
> the performance of the stat-avoiding optimization?

Yes!  My Debian bug report even describes one!  How do you think I
discovered this problem ?

> > It always used to be.
> 
> No, GNU ls has not always used this optimization.

Then GNU ls has always had this bug.  By `always' I meant in UN*X.

Ian.