On Mon, 7 Jul 2008, Ian Jackson wrote: > > When files are only in a single filesystem the inum is sufficient to > uniquely identify a file. But when we consider more than one > filesystem, the inum and device are needed together because inums on > different filesystems are unrelated and may be (often are) the same. > > Thus any program which uses _only_ inums to tell files apart is broken > if it works near a mountpoint. Either the documentation for or > filesystem layout used by that program must ensure that mountpoints > are not relevant, or the program must take extra special care somehow > itself. ls -i prints only inums. So by using ls -i a program > promises that mountpoints are not relevant.
Thinking along the same lines... It is correct to pair the d_ino values from readdir() with the st_dev value of the directory to identify unique files within a single directory. This is because, according to POSIX, (1) Mount points have to be directories and directories can't be hard- linked [*], so a sub-directory's d_ino is unique whether or not it is a mount point. Therefore only non-directories can have duplicate d_ino numbers. (2) All non-mount-points have the same st_dev as their parent, since the definition of mount points is that only they have a different st_dev number from their parent directory. Therefore it isn't necessary to lstat() each non-directory to find out its st_dev number. If the d_ino of a mount point comes from the mounted file system instead of the underlying one then this logic breaks, because the d_ino of a sub-directory is no longer guaranteed to be unique. Such a change would make the d_ino value entirely useless because you would have to lstat() every directory entry to get a meaningful dev+ino pair. [*] The logic also breaks on crufty old systems that permit root to cause exciting filesystem breakage by hard-linking directories. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ CROMARTY FORTH: VARIABLE, MAINLY NORTH 3 OR 4, OCCASIONALLY 5 LATER. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
