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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
