Re: Bug#369822: ls -i stats unnecessarily

[Paul Eggert]

Ian Jackson <address@hidden> writes:

> the inum on its own isn't useful if you don't know either (a) there
> are no mountpoints here or (b) exactly where the mountpoints are.

No, it can be useful.  For example, suppose you have the inum Fi of
some other file F, and want to know whether this directory entry could
be that of F.  If readdir returns d_ino == Ri, and if Ri != Fi, then
you know that it can't possibly be a match.  This sort of optimization
can be quite useful to avoid a stat, but it doesn't work if d_ino
might be junk from an underlying file system.

On operating systems where d_ino might be junk at mount points, we
have to suppress optimizations like this.  On operating systems where
d_ino is reliable at mount points, our code can run faster.

> If you know it's a mounted filesystem, you can ask
>   ls -id /mount/point/.

Sure, but I shouldn't have to ask "pretty please, can I get the
correct inode number?"  readdir should give me the correct inode
number in the first place.

> Eg,
>   inum=`ls -id /unexpected/mount/point/.`
>   find / -xdev -inum $inum
> isn't going to work properly !

Sure it works properly.  Any file in the subsidiary file system will
have an inode number that is allocated independently of inode numbers
of files in the root file system.  If I changed the example to this:

   inum=`ls -id /unexpected/mount/point/somefile`
   find / -xdev -inum $inum

then that works "properly", in that it attempts to find a file in the
root file system whose inode number is the same as the inode number of
"somefile".  Your example should work the same way, with "." rather
than "somefile".


Anyway, I just now checked Posix on this and found that it allows
implementations of readdir to return a random value for d_ino!  Wow.
I filed an Aardvark about it here, which you are welcome to follow up:

http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-review-l&id=2070