Tony Finch <[EMAIL PROTECTED]> writes: > Also, readdir(3) is not the only part of POSIX that needs clarifying.
I participated in the discussion that resulted in this new d_ino wording being added to POSIX, and my recollection is that the common behavior where readdir returns the inode number of the underlying mount point is now considered to be a bug, both for readdir purposes and for ls -i purposes (as well as for find -inum purposes). That is, these functions are now all supposed to use the inode number of the root of the mounted file system, and this is supposed to be the same number for all purposes; and the underlying mount point's inode number is supposed to be inaccessible via the standard interfaces. If there's any further question about this it might help to track down the relevant Austin Group discussion. Oould argue that this is really a readdir bug, not an ls -i bug, and that (pragmatically, for efficiency reasons) it may be better for the GNU "ls" maintainer to punt and tell users to get a working kernel. On the other hand, there is a long tradition of GNU tools working around bugs in the underlying operating systems. I don't think this is a slam-dunk decision either way. Still, given the arguments I've seen so far I'd favor having coreutils work around the bug unless the performance penalty is really, really bad. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
