2017-06-09 15:46:56 +0100, Stephane Chazelas:
[...]
> In addition to leaving it unspecified whether a "." or ".."
> entry is returned, we may also want to clarify (or leave
> unspecified) what d_ino the ".." entry may have for mount-points
> and that in any case, there's no guarantee that it would be the
> same as the inode returned by a stat("..").
>
> Do we guarantee that all the d_ino returned by readdir() are
> from the same file system?
>
> The rationale part seems to say the opposite which is against
> current practice AFAICT.
>
> SUSv4TC2> When returning a directory entry for the root of a mounted
> SUSv4TC2> file system, some historical implementations of readdir()
> SUSv4TC2> returned the file serial number of the underlying mount
> SUSv4TC2> point, rather than of the root of the mounted file system.
> SUSv4TC2> This behavior is considered to be a bug, since the
> SUSv4TC2> underlying file serial number has no significance to
> SUSv4TC2> applications.
>
> That's not at all what I observe. On Solaris 11:
[...]
> Same on GNU/Linux (though GNU ls would use lstat() to get the inode
> numbers).
[...]
Same on FreeBSD (whose ls -i behaves like Linux' (displays the
inode number from lstat(), not from readdir()).
In any case, either value (the inode of the file or the inode of
the file in the original filesystem the file is mounted on) is
not useful.
- In the first case (the one required by POSIX)
OK it's the "correct" inode number (the one we would get from
lstat() on that path), but we don't know what file system it's
for as it's a different one from the one of the directory
we're listing. That also means that we can get different
entries with the same d_ino even though they are not hardlinks
(it's common for the root directory to file systems to have a
fixed low-number inode number (typically "2" on ext4).
- In the second case (the one in FreeBSD, Linux and Solaris at
least), that's the inode number of a file we
cannot access by that path (and again, applications using
d_inos to detect hard links could be fooled).
One could imagine a third approach where we return a
INO_DIFFERENT_FILESYSTEM special reserved number to warn the
application they can't reliably use that d_ino.
So we might as well leave the behaviour unspecified.
And maybe note in "application usage" that the d_ino cannot be
relied upon and people should use lstat().
However, for lstat(), they need search access to the directory.
ls -i "works" on Solaris (except it returns the wrong inode
numbers for mount points) on directories you don't have search
access to, but not on Linux or FreeBSD.
Something probably worth noting in the "ls" spec (that it's
unspecified what you get for the inode number of mount points
and it's unspecified whether you may obtain inode numbers when
you don't have search permission to the directory).
--
Stephane
