Date: Fri, 4 Jun 2021 14:29:51 -0000 (UTC)
From: mlel...@serpens.de (Michael van Elst)
Message-ID: <s9ddcv$a30$1...@serpens.de>
| We need to understand why namei() does this check and how it can be
| corrected.
Yes, I was wondering about that, it seems to make no sense to me.
A mountpoint, by definition, must exist, so the O_CREAT flag (without
O_EXCL) will never be creating anything, so if we hit a mountpoint
boundary, just at the resolution of the name, the result cannot be
affected by O_CREAT (alone - O_CREAT|O_EXCL is always going to fail,
mountpoint or not, if the target name exists).
Simply removing whatever the test is should (hypothetically anyway)
make no difference to anything, so discovering why the check was added
would be useful.
I've been taking a bit of a look at the history, and while the error
wasn't always EEXIST (that's only from 2011) the test has been there
for ages. At the minute I'm thinking it might be a deficit in the
design of the vnops ... the error comes from a "create" operation on
a mount point, which obviously is going to fail (as do delete and rename).
The problem is that O_CREAT isn't always a create op, it can simply be
a lookup, it only turns into an actual create operation if the target
doesn't exist.
Perhaps that means the way the create vnop works needs to be altered, or
perhaps this test doesn't really need to be there, as if it is really
intended to be a create (as in mkdir() or link()) it should simply fail
when it detects the target exists (mount point or not) and if it is an
"optional create" (as on O_CREAT on open) then if the target exists
it isn't really a create at all.
I think I am going to experiment with simply removing that error case
and see if anything breaks.
kre
