Description of problem:
/bin/ls -i / ignores mount points and shows underlying filesystem
inode numbers.

Version-Release number of selected component (if applicable):
$ ls --version
ls (GNU coreutils) 6.9
$ rpm -q coreutils
coreutils-6.9-9.fc7


How reproducible:
Always

Steps to Reproduce:
1. /bin/ls -i /
2. /bin/ls -i -color=auto
3.
  
Actual results:
$ cd /
$ /bin/ls -i
 648321 bin    907649 home         162081 misc   842817 proc     1329057 srv   
   1977377 usr
 680737 boot   226913 lib         2463617 mnt   2301537 root     1718049 sys   
    583489 var
2269121 dev        11 lost+found   486241 net   1426305 sbin      713153 tftpboot
1102145 etc   1944961 media       1588385 opt   1912545 selinux  2236705 tmp
$ /bin/ls -i --color
 648321 bin         2 home           6954 misc        1 proc     1329057 srv   
         2 usr
      2 boot   226913 lib         2463617 mnt   2301537 root           1 sys   
         2 var
    197 dev        11 lost+found     6957 net   1426305 sbin      713153 tftpboot
1102145 etc   1944961 media       1588385 opt         1 selinux        2 tmp


Expected results:
$ /bin/ls -i
 648321 bin         2 home           6954 misc        1 proc     1329057 srv   
         2 usr
      2 boot   226913 lib         2463617 mnt   2301537 root           1 sys   
         2 var
    197 dev        11 lost+found     6957 net   1426305 sbin      713153 tftpboot
1102145 etc   1944961 media       1588385 opt         1 selinux        2 tmp
$ /bin/ls -i --color
 648321 bin         2 home           6954 misc        1 proc     1329057 srv   
         2 usr
      2 boot   226913 lib         2463617 mnt   2301537 root           1 sys   
         2 var
    197 dev        11 lost+found     6957 net   1426305 sbin      713153 tftpboot
1102145 etc   1944961 media       1588385 opt         1 selinux        2 tmp


Additional info:

I posted this as a question on comp.unix.shell on 6/30/08, ""Gnu ls bug?",
and had the bug confirmed on other Linux systems as well.

Stephane Chazelas (a smart guy) added this:
<quote>
Could be a Linux bug. With -i alone, ls gets the inode number
from readdir, which if you have --color, ls does a lstat to get
the type of file (directory, regular...) and gets the result
from there.

So with -i alone, you get the inode of the dir entry in the
parent filesystem while with other options that trigger the call
of lstat(2), you get the inode of the mount point.
</quote>

Also, Geoff Clare (another smart guy) wrote:
<quote>
Yes, this is a known bug in some implementations of readdir(),
although I didn't think any modern systems suffered from it.

It is mentioned in the rationale for readdir() in the new POSIX
revision:

    When returning a directory entry for the root of a mounted file
    system, some historical implementations of readdir() returned the
    file serial number of the underlying mount point, rather than of
    the root of the mounted file system. This behavior is considered
    to be a bug, since the underlying file serial number has no
    significance to applications.
</quote>

So, this is a bug that manifests with ls, but might be a bug in the kernel
system call or glibc, I don't know which.

I marked this bug as "urgent" since reporting incorrect inode numbers can break
backups, and reporting underlying "hidden" inode numbers represents a security risk.