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

[Phillip Susi]

Jim Meyering wrote:
> Ultimately, neither POSIX nor any other official standard defines what
> is "right" for coreutils.  POSIX usually serves as a fine reference, but
> I don't follow it blindly.  In rare cases I've had a well-considered
> disagreement with some aspect of a standard, and I have implemented
> default behavior that technically makes an application non-conforming.
> The standard evolves, too.

Going against the standard behavior is not strictly anathema, true, but 
you had better have a good reason for it.  This 'fix' gains NOTHING 
since any application ( whether it exists now or conceivably could in 
the future ) that depends on your preferred behavior is already 
inherently broken.  With nothing to gain, and both conformance and 
performance to loose, this fix seems to be bad form.

> > Furthermore it _is_ right even in absolute terms.
>
> Then we'll have to agree to disagree.

So far your well-considered disagreement with the standard seems to 
consist solely of "it is confusing that the two inum's don't match". 
That seems a fairly weak argument for technical correctness.  While I 
agree that your way makes more sense, that alone does not outweigh both 
performance and conformance.  There are plenty of things that don't seem 
to make sense at first glance, but we still do them with good reason.

> When ls -i prints an inode number not equal to the one lstat would
> produce, I consider it inaccurate.
> ls -ldi DIR prints an accurate inode number for DIR.
> ls -i DIR/.. |grep DIR fails to do so when DIR is a mount point
> (but works on Cygwin)

I would argue that it is not inaccurate, since as far as correct 
operation of the machine is concerned, it has no effect.  The perceived 
inaccuracy is only in your own mind while you incorrectly attempt to 
assign meaning to the value which has none.  To justify the cost of 
conformance and performance, something a bit more substantial than 
making a human feel better needs to be achieved.

> > There are *no existing programs* and *no plausible correct programs*
> > which depend on your new behaviour.
>
> Easy to say.  Even if it were known to be true,
> imho, it's irrelevant, since your definition of "correct"
> presupposes the broken behavior.

You seem to have this backwards.  Ian's definition of correct 
presupposes that the inums are useless in the presence of mount points 
in the first place, which they are without a dnum.  It is your 
definition of correct that is founded solely on what you feel the 
behavior should be, which by all logical measures, is broken.

You have no logical reason for arguing that your way is "correct" other 
than that you find the other way unsettling.

> Not yet.  But I haven't done a complete survey, either.
> Maybe this exposure will prod the affected systems to provide
> a readdir-like interface with always-lstat-consistent d_ino values.

I'd bet money that Linux won't since there zero reason to do so, and 
several reasons not to.