Re: Anyone interested in implementing O_NOCLOBBER ?

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

    Date:        Fri, 17 Apr 2020 18:15:01 +0200
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20200417161501.GB72370%bec.de@localhost>

  | I'm talking about the difference between this new clobber flag and
  | O_EXCL.

OK.

  | As in: why doesn't the noclobber flag just set O_EXCL and done.

That's largely what it does these days, but it doesn't work.

  | As in: it seems reasonable to me to just do the
  | device check afterwards,

That's exactly what is generally done.   But that leaves race
conditions, and is possible to defeat.

If all that matters is noclobber mode as originally intended, there
is no genuine problem, and no-one would have ever considered any of this,

The problem is that the world (or some section of it) has apparently
decided that noclobber mode ought to work for reliably doing sh
level locking primitives (as in, critical regions, etc).   For that,
race conditions such that things sometimes fail are unacceptable.
And "generally not" doesn't work at the level that matters.

Once again, I think this is an abuse of the sh's noclobber mode,
and we should do nothing at all to encourage it to be used as a
mechanism for implementing locking - but I'm not sure it is possible
to push that genie back into the bottle.

It seems as if O_NOCLOBBER will become mandatory (feel free to
got into the Austrin Group and argue against it) either in Issue 8
(looks like it might appear next year) or in Issue 9 (a decade or
so away probably ... but Issue 8 will "strongly suggest" that
implementations should include it).

It doesn't bother me in the slightest if we decline to implement it
now (fortunately no-one in the NetBSD world is complaining that our
noclobber mode isn't reliable enough for their locking script, or not
that I know of anyway) - and if we like, perhaps forever.  It wouldn't
be the first part of POSIX that we simply ignore.

kre