All of lore.kernel.org
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC v1] man/man3/readdir.3, man/man3type/stat.3type: Improve documentation about .d_ino and .st_ino
Date: Wed, 28 May 2025 17:54:35 -0500	[thread overview]
Message-ID: <20250528225435.cj2agonqjkqqowwg@illithid> (raw)
In-Reply-To: <c27a2d7f80c7824918abe5958be6b5eb2dbe8278.1748467845.git.alx@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

At 2025-05-28T23:31:29+0200, Alejandro Colomar wrote:
[snip]
> diff --git a/man/man3/readdir.3 b/man/man3/readdir.3
[snip]
> +If the directory entry is the mount point,
> +then
> +.I .d_ino
> +differs from
> +.IR .st_ino :
> +.I .d_ino
> +is the inode number of the underlying mount point,
> +while
> +.I .st_ino
> +is the inode number of the mounted file system.
> +According to POSIX,
> +this Linux behavior is considered to be a bug,
> +but is nevertheless conforming.
>  .TP
>  .I .d_off
>  The value returned in

Can someone add a *roff comment supporting the claim in the second
sentence?  For example, could we have a citation to an Austin Group
mailing list post or a ticket in the group's Mantis bug tracker?

I've followed the Austin Group mailing list for years and, to me, it
sounds uncharacteristic of the POSIX developers to decree an
implementation as "conforming but buggy".

I've checked Draft 4 (the final draft) of the 2024 standard, and see
nothing to support this claim in its dirent.h or readdir() pages.
Typically, if an implementation is "getting away with" something that
the Austin Group finds objectionable, they anticipate and give notice of
a potential change in semantics or of a planned interface removal in the
"Future Directions" sections of their entries.

It's possible I overlooked something.  I used text search rather than
reading all 4,101 pages of the standard at a sitting.  (I count only 9
total matches for `d_ino`; all are in the aforementioned 2 entries, or
[new to Issue 8] posix_getdents().)

There may be something analogous to the mount point situation in the
case of symbolic links, which the standard _does_ contemplate:

"The value of the [dirent] structure's _d_ino_ member shall be set to
the file serial number of the file named by the _d_name_ member.  If the
_d_name_ member names a symbolic link, the value of the _d_ino_ member
shall be set to the file serial number of the symbolic link itself."
(p. 1858, lines 61297-61299)

...which leads me to wonder what an implementation--Linux,
specifically--decides the right thing is when one readdir()s a symbolic
link to a mount point.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2025-05-28 22:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-25 10:33 Improving inode number documentation Pali Rohár
2025-05-25 23:30 ` Alejandro Colomar
2025-05-28 18:25   ` Pali Rohár
2025-05-28 19:03     ` Alejandro Colomar
2025-05-28 19:41       ` Pali Rohár
2025-05-28 19:59         ` Alejandro Colomar
2025-05-28 21:31           ` [RFC v1] man/man3/readdir.3, man/man3type/stat.3type: Improve documentation about .d_ino and .st_ino Alejandro Colomar
2025-05-28 22:54             ` G. Branden Robinson [this message]
2025-10-28 23:15           ` [PATCH v2] " Alejandro Colomar
2025-10-28 23:53             ` Pali Rohár
2025-10-29  7:00               ` G. Branden Robinson
2025-10-29 19:34                 ` Pali Rohár
2025-11-21 21:10                   ` Pali Rohár
2025-11-21 23:39                     ` G. Branden Robinson
2025-11-22  0:53                       ` Pali Rohár
2025-10-30 11:58             ` Jan Kara
2025-10-31 10:44           ` [PATCH v3] " Alejandro Colomar
2025-10-31 10:56             ` Jan Kara
2025-10-31 11:31               ` Alejandro Colomar
2025-10-31 17:10                 ` Pali Rohár
2025-10-31 15:25             ` Darrick J. Wong
2025-11-02 21:17               ` Alejandro Colomar
2025-11-03 11:28                 ` Jan Kara
2025-11-09 12:07                   ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250528225435.cj2agonqjkqqowwg@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.