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

[Wayne Pollock]

Jim Meyering wrote:
> Phillip Susi <address@hidden> wrote:
> > The new POSIX standard verbiage you
> > pointed out only _hints_ that that it is incorrect behavior, with no
> > justification for that position.

I know ls didn't use to work this (buggy!) way on old versions of
Linux.  I don't think it did on AIX either, but my memory isn't
that clear.  I reported the problem because when teaching about
filesystems I projected "ls -l /" to the class but the wrong
inodes appeared.  They didn't used to!  Worse, the students
said they saw different inode numbers than shown on the projection.
Turns out that I had unaliased ls (to turn off the color option as
that doesn't project well).  So I was running "/bin/ls -i /" but
the students were running "/bin/ls -i --color=auto /".

To me, it is a bug if adding color to the output changes the
reported inode numbers.  You must, for the sake of consistency,
get the same values if running ls -i with or without other
options such as -l, --color, -F, etc.

[I didn't report it earlier but "/bin/ls -iF" shows the incorrect
(underlying) inode numbers, even though it seems likely that
Gnu ls should do the same system/library calls for -F as for
"--color=auto".  Hope the Gnu maintainer checks into that.]

How can either ls or readdir be considered correct when
the output is so inconsistent?  What behavior do you expect from
backup scripts (and similar tools) that use find (or readdir)?
It seems clear to me that returning the underlying inode numbers
must result in having the wrong files backed up in this case.

If some folk feel the underlying numbers reported by the
(buggy; sorry but I don't know what other adjective to use) readdir,
then for the sake of consistency stat must be considered buggy
for reporting the root inode number of mount points.  "Consistency
first, and performance be damned!"

From my (admittedly inexpert) point of view the inode of the underlying
filesystem directory is useless except to find "hidden" files.  So
the stat behavior, even if useless without a device number too, is
the better value to return in all cases.

It might be argued which value is better, but inconsistent values
(and perhaps unpredictable values without reading the source code)
are clearly wrong.

The POSIX standard is correct in my opinion; glibc is currently buggy.
I would claim (and I guess I did) that this behavior is buggy even
if every Unix system in the universe always worked this way.
A long standing bug is still a bug.

-Wayne Pollock