Ian Jackson <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
