Paul Eggert writes ("Re: Bug#369822: ls -i stats unnecessarily"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > This behaviour is expected: if you readdir the directory containing
> > a mountpoint, you get the inode number of the directory in the
> > underlying filesystem;
>
> That's not the behavior that I expected. Also, it's not useful
> behavior--at least, it's not useful for the vast majority of
> real-world applications. In contrast, it is useful for 'ls -i' to
> print the inode number of the root of the mounted file system, for
> 'find -inum' to use that inode number, and so forth.
If you know it's a mounted filesystem, you can ask
ls -id /mount/point/.
instead of
ls -id /mount/point
If you don't know it's a mounted filesystem then the inode number of
the mounted filesystem is useless to you. Eg,
inum=`ls -id /unexpected/mount/point/.`
find / -xdev -inum $inum
isn't going to work properly !
> I can understand why readdir might have the behavior that you
> describe: it might be more efficient internally. But that doesn't
> make it correct, or even "expected". It's a bug in readdir.
You might say that it's a deficiency in the readdir interface, as well
as in ls -i, etc. etc., that it doesn't provide the dev as well as the
inum. But however you look at it, 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. In case (a) you don't care about the
distinction; in case (b) you can compensate with stat.
Ian.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
