Re: [RFC PATCH v5 1/2] vfs: add O_CREAT|O_DIRECTORY to open*(2)

[NeilBrown]

On Fri, 29 May 2026, Christian Brauner wrote:
> On Fri, May 29, 2026 at 09:58:29AM +1000, NeilBrown wrote:
> > On Thu, 28 May 2026, Christian Brauner wrote:
> > > On Thu, May 28, 2026 at 08:17:31AM +1000, NeilBrown wrote:
> > > > On Wed, 27 May 2026, Christian Brauner wrote:
> > > > > > 
> > > > > > I'm not convinced the change to EOPNOTSUPP is a good idea.  It should
> > > > > > be a separate patch so that it can be reviewed separately.
> > > > > > 
> > > > > > EOPNOTSUPP is documented as
> > > > > >        EOPNOTSUPP      Operation not supported on socket (POSIX.1-2001).
> > > > > > 
> > > > > > and we have no sockets here!
> > > > > 
> > > > > Sorry, not even userspace tooling indicates that this has anything to do
> > > > > with sockets.
> > > > > 
> > > > >     > which errno
> > > > >     /usr/bin/errno
> > > > > 
> > > > >     > errno ENOTSUP
> > > > >     ENOTSUP 95 Operation not supported
> > > > >     
> > > > >     > errno EOPNOTSUPP
> > > > >     EOPNOTSUPP 95 Operation not supported
> > > > 
> > > > $ man 3 errno | grep EOPNOT
> > > >      EOPNOTSUPP      Operation not supported on socket (POSIX.1-2001).
> > > >                      (ENOTSUP and EOPNOTSUPP have the same value on Linux,  but
> > > 
> > > (ENOTSUP and EOPNOTSUPP have the same value on Linux, but according to POSIX.1 these error values should be distinct.)
> > > 
> > > Consistency be damned, I guess.
> > > 
> > > And if we start caring about POSIX again we should probably remove 90%
> > > of our newer apis. It's irrelevant what the standard says. It matters
> > > what we do in practice. Taking a tour through the kernel and trying to
> > > prove that there's any 1:1 relationship between socket operations and
> > > EOPNOTSUPP fails. Equally, going through large userspace projects to see
> > > whether they treat EOPNOTSUPP as even vaguely socket related also fails.
> > > 
> > > Even glibc treats EOPNOTSUPP as the universal "not supported" sentinel
> > > and raises it even independent of what the kernel returns. One example I
> > > distincly remember is the fchmodat() AT_SYMLINK_NOFOLLOW userspace
> > > emulation it had to do.
> > > 
> > > Maybe I really misunderstand the motivation for this discussion. But
> > > this feels a bit like wasting time on something that we've already
> > > established a while ago.
> > > 
> > 
> > Maybe someone should update the man-page?
> 
> Yeah, someone did yesterday actually and it was merged the same day.

That's very efficient!!   Thanks Askar!

NeilBrown

> 
> > My main point was not that EOPNOTSUPP was a poor choice, but that an API
> > change needs to be managed properly (and I'm not sure it is worth it in
> > this case).
> 
> Right. That's certainly a valid concern!
>