Bug 453709

Summary: ls -i reports incorrect inode numbers
Product: [Fedora] Fedora Reporter: Wayne Pollock <pollock>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: meyering, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: coreutils-7.5-3.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-01 08:50:33 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Wayne Pollock 2008-07-02 01:37:39 EDT
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.
Comment 1 Matěj Cepl 2008-07-02 03:15:32 EDT
Fedora 7 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 8, or Fedora 9,
or Rawhide)? If this issue turns out to still be reproducible, please let us
know in this bug report.  If after a month's time we have not heard back from
you, we will have to close this bug as INSUFFICIENT_DATA.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.
Comment 2 Ondrej Vasik 2008-07-02 03:25:48 EDT
Thanks for report, still reproducable even with rawhide (and latest upstream GIT
snapshot as well). Therefore adding upstream maintainer of coreutils to CC.
Comment 3 Jim Meyering 2008-07-02 06:59:19 EDT
Thanks for the report, Wayne, and for the Cc, Ondrej.
This was discussed at length a couple years ago in this thread:
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/97637

I'm looking into what it'll take to detect the losing readdir -- maybe even at
configure-time.
Comment 4 Jim Meyering 2008-07-07 04:40:55 EDT
FYI, I'm planning to fix this and have outlined most of the solution here:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14020
Comment 5 Tony Finch 2008-07-07 09:53:10 EDT
The expected traditional behaviour of readdir() is to return the inode number of
the underlying filesystem, not the mount point. This is true on BSD as well as
Linux, and is permitted by POSIX.

The POSIX spec implies that ls(1) should return the same inode number that
stat(2) does, which is not entirely sensible since that would cause unhelpful
results for sybbolic links. BSD ls(1) prints the inode number from lstat(2).
Comment 6 Bug Zapper 2008-11-25 21:29:50 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Ondrej Vasik 2009-07-17 03:33:01 EDT
Decreasing severity to medium. In the thread mention in comment #4 Jim requested to name any affected application - only one was named - magicmirror. AFAIK Jim is going to fix this - once the time frame allows, so I hope it's still in his TODO list. Changing version to RAWHIDE again...
Comment 8 Ondrej Vasik 2009-08-31 04:18:08 EDT
Upstream plans to fix the issue for 7.6 - here is Jim's proposed patch : http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00320.html
Comment 9 Ondrej Vasik 2009-09-01 08:50:33 EDT
Fixed in coreutils-7.5-3.fc12 , closing RAWHIDE.