From: Linus Torvalds <torvalds@linux-foundation.org>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Christian Brauner <brauner@kernel.org>,
Pedro Falcato <pedro.falcato@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] do_open(): Fix O_DIRECTORY | O_CREAT behavior
Date: Mon, 27 Mar 2023 20:32:59 -0700 [thread overview]
Message-ID: <CAHk-=wgLimhZ8px+BxTvkonBGHr9oFcjrk4tmE2-_mmd3vBGdg@mail.gmail.com> (raw)
In-Reply-To: <ZCJN0aaVPFouMkxp@localhost>
On Mon, Mar 27, 2023 at 7:15 PM Josh Triplett <josh@joshtriplett.org> wrote:
>
> If there are no users of this and we can clean up the semantics, is
> there a strong reason *not* to make `O_DIRECTORY | O_CREATE` actually
> create a directory and atomically return a file descriptor for that
> directory? That seems like genuinely useful behavior that we don't
> currently have a syscall for. I didn't see any suggestion in the thread
> for reasons why we can't or shouldn't do that.
Absolutely not.
For one thing, it is clearly not "genuinely useful behavior". It's just stupid.
Name a *single* real situation where that would be a big improvement?
Point to code, and point to a reason, and point to why it would make a
difference. No made-up hypotheticals.
If you want to open a directory, just do that
fd = open(.., O_DIRECTORY);
and if that directory doesn't exist, and you still want to create it,
then just do
mkdir(...);
on it. Done. And mkdir() is atomic, so there's no race there with
somebody else doing something else to that path.
And no, there is no race with a subsequent open of that mkdir case,
because you already know the result empty, so what would you do with
the fd you just got? Absolutely nothing. It's useless. Edwin Starr
sang a song all about it.
So there is *zero* real reasons for that "open a directory and create
it atomically". It's a nonsensical operation.
Ok, just to play along - maybe you can make it slightly less
nonsensical by throwing O_PATH into the mix, and now an empty
directory file descriptor at least has *some* use.
But even *if* you can point to such a thing being useful (and I'm
really doubtful), it would *still* be stupid.
Now your code would not only be specific to Linux, it would be
specific to some very new version of Linux, and do something
completely different on older versions.
Because those older versions will do random things, ranging from
"always return an error" to "create a regular file - not a directory -
and then return an error anyway" and finally "create a regular file -
not a directory - and return that resulting fd".
So no. We're not adding a *fourth* set of semantics to something that
is silly and useless to do in the first place, and that has already
had three existing semantics.
The reason it has had three different behaviors over the years is
*literally* that nobody has ever wanted to do it, and so the fact that
it has been broken for years hasn't even mattered.
Don't try to make that situation worse by then making up new pointless
meanings for it and try to come up with excuses why somebody would
want to do that operation.
Linus
next prev parent reply other threads:[~2023-03-28 3:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 7:14 [PATCH] do_open(): Fix O_DIRECTORY | O_CREAT behavior Pedro Falcato
2023-03-20 11:51 ` Christian Brauner
2023-03-20 17:14 ` Linus Torvalds
2023-03-20 19:27 ` Pedro Falcato
2023-03-20 20:24 ` Linus Torvalds
2023-03-20 22:10 ` Aleksa Sarai
2023-03-21 14:24 ` Christian Brauner
2023-03-21 16:17 ` Christian Brauner
2023-03-21 17:35 ` Linus Torvalds
2023-03-21 20:16 ` Christian Brauner
2023-03-21 21:47 ` Linus Torvalds
2023-03-22 10:17 ` Christian Brauner
2023-03-22 17:07 ` Linus Torvalds
2023-03-27 20:13 ` Pedro Falcato
2023-03-28 8:12 ` Christian Brauner
2023-03-28 2:15 ` Josh Triplett
2023-03-28 3:32 ` Linus Torvalds [this message]
2023-03-28 4:00 ` Josh Triplett
2023-03-28 7:57 ` Christian Brauner
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='CAHk-=wgLimhZ8px+BxTvkonBGHr9oFcjrk4tmE2-_mmd3vBGdg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=josh@joshtriplett.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pedro.falcato@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).