Re: st_nlink of directory nodes in shadowfs

[Roland McGrath]

Oy!  I had no idea find did that, though I suppose it is reasonable.  

By my reading of 1003.1-1996, st_nlink should be "the number of directory
entries that refer to the file".  In a case like this, I think it's pretty
open to interpretation what constitutes a directory entry; there always
might be extra entries in some directory you don't know about, and that is
not distinguishable from st_nlink just being too high.

I'm also not entirely sure how kosher find's use of st_nlink on directories
is, by the POSIX rules.  I haven't done a thorough search, but `..' is
described as a "special file name", and it is unspecified whether readdir
returns entries for `.' and `..', so I tend to conclude that there is no
requirement about `..' being a normal link as to contribute to the link
count in a well-specified way.

All that leads me to conclude that all that matters is what makes find
happy in practice.  If it uses st_nlink to limit the number of entries in
the directory it stats for directoriness, then an inflated count only makes
it possibly less efficient and won't make it incorrect.

Note, however, that this optimization in find will quite totally break the
filesystem semantics presented by translators set on regular files.  That
is, a translator set on a regular file may well report S_IFDIR and so a
find ought to treat it as a directory.  But the underlying node isn't a
directory and so doesn't have a .. node contributing to the containing
directory's link count.