Re: procfs files vs symlink

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 13 Jan 2022 21:12:51 +0000 (UTC)
    From:        RVP <rvp%SDF.ORG@localhost>
    Message-ID:  <c6445584-c6b2-55d6-4ea6-fc28d858ecab%SDF.ORG@localhost>

  | The patch is for processes to know that stat() will have to be
  | called for that particular dirent.

Yes, I understood the patch.  But why?

  |  DT_REG would not be right there.

Not always.  No.  But if the fd refers to a regular file,
it would be, right?

  | (I've done this myself: call stat() if dirent.d_type is DT_UNKNOWN;
  | otherwise, take dirent.d_type as valid and save a syscall.)

Sure, d_type is an optimisation.  Since procfs knows what types
of files it has -- either it is creating them, or they come from
an open fd, which has a known type -- why not implement the
optimisation?

  | A note in dirent.3 that procfs (and some others?) will always return
  | DT_UNKNOWN would be a good idea, I think.

DT_UNKNOWN is intended for filesystems with directories that do not
maintain the d_type field, and so would need to fetch the inode (or
its equivalent) to supply the type - which would be relatively harmless
when the application follows the readdir with a stat on each entry,
but is needless overhead when the application does not care.

If procfs is not setting d_type correctly, that should be fixed.
(Which does not mean setting the type to unknown, when it is known.)

If your patch makes any difference to the way ls /proc/self/fd
works, that is just a fluke (relates to the way ls happens to
sequence its operations) and in no way any kind of general fix.

kre