Re: procfs difference between NetBSD and Linux

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

    Date:        Fri, 04 Jun 2021 10:32:24 +1000
    From:        Simon Burge <simonb%NetBSD.org@localhost>
    Message-ID:  <20210604003224.CC9B44E23A%thoreau.thistledown.com.au@localhost>

  | https://pubs.opengroup.org/onlinepubs/007908799/xsh/open.html doesn't
  | mention anything about what filesystem types back the path being opened.

No, but there are lots of other things also not mentioned that also
affect what posix requires.    Eg: and somewhat bizarrely, if the process
in question was started with one (or more) of fds 0 1 or 2 closed, then
what happens would also be unspecified.   There the underlying issue is
that the open might (in fact, would) return the lowest of the closed ones
of those which isn't what applications expect, and so bizarre things happen.

But POSIX has no notion of types of bizarre, there is just unspecified
(something happens, but implementations get to decide), undefined (anything
goes, reasonable or not) and specified.   As soon as you move out of the
POSIX defined environment, everything becomes unspecified or undefined.

Obviously, it wouldn't be useful to take liberties, we wouldn't want
open("/dev/null", 0) to call abort() just because the system has a
procfs mounted, and particularly if  the application isn't using it.
But POSIX doesn't say we cannot.   This is simply outside the standard.

  | It does say that O_CREAT without O_EXCL should have no effect if the
  | files exists.

Yes, and obviously, wherever possible, that's what should happen, it is
just that you cannot say "required for POSIX conformance" when the file
is on a filesystem that doesn't conform with POSIX.

  | That this particular instance is related to procfs
  | shouldn't make a difference, right?

I'm not aware of any discussions related to procfs type filesystems
related to POSIX (doesn't mean there have never been any) but this
type of issue comes up from time to time related to NFS, which also
has slightly different semantics than "normal" filesystems - and I
believe the answer has always been that as soon as you step away from
a POSIX environment, the requirements no longer apply.

Files and operations on an NFS filesystem aren't required to behave the
same way as files on a normal filesystem (which is good, as they don't).

kre

ps: if we were to be overly cynical, we could also say that to conform
to POSIX all that is required (of the implementation, leaving aside for
now all the paperwork etc required of the implementors) is that the system
pass the POSIX conformance tests.   Those have no procfs (or NFS) because
those things are not POSIX.   Hence testing O_CREAT on a /proc/$$/fd/N
type file name will never be done (or it could be, but it would just be
a regular file in a regular directory, and irrelevant here), and so cannot
cause a system to fail, whatever it does.