Date: Fri, 04 Jun 2021 10:32:24 +1000 From: Simon Burge <sim...@netbsd.org> Message-ID: <20210604003224.cc9b44e...@thoreau.thistledown.com.au>
| 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.