How about O_CREAT_DIRECTORY? [LWN.net]

How about O_CREAT_DIRECTORY?

Posted Jul 30, 2026 14:16 UTC (Thu) by corbet (editor, #1)
In reply to: How about O_CREAT_DIRECTORY? by davecb
Parent article: Reconsidering O_CREAT|O_DIRECTORY

One problem, as always, is that open() does not check its flags for validity, so it is almost impossible to add new ones in a safe way.

Besides, we would want O_CREATE_DIRECTORY, it's not the 1970s anymore :)

to post comments

How about O_CREAT_DIRECTORY?

Posted Jul 30, 2026 16:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Besides, we would want O_CREATE_DIRECTORY, it's not the 1970s anymore :)

Not to mention that "spelling `creat` with an 'e'` was one thing that Ken Thompson would have changed about Unix given a redo.

https://en.wikiquote.org/wiki/Kenneth_Thompson

How about O_CREAT_DIRECTORY?

Posted Aug 2, 2026 9:57 UTC (Sun) by wjb (subscriber, #71810) [Link]

It's a feature of fixed length naming conventions (or strings) that the length being one character longer would have been better.

How about O_CREAT_DIRECTORY?

Posted Jul 30, 2026 16:05 UTC (Thu) by ejr (subscriber, #51652) [Link]

I still work in the BLAS/LAPACK community. Keeping the olde names is a point of pride to some. ;)

How about O_CREAT_DIRECTORY?

Posted Jul 30, 2026 20:28 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (1 responses)

> Besides, we would want O_CREATE_DIRECTORY, it's not the 1970s anymore :)

Yes, and no. I think consistency is more important.

While creat(2) is a well-known example of what we would have all done different with a time machine, now that we have O_CREAT, if we're adding a new flag that is a sibling of it, it should be O_CREAT_xxx. That way, users can immediately expect that it does essentially the same as O_CREAT, with the minor difference related to the trailing of the name. Otherwise, one could legitimately wonder why it's CREATE instead of CREAT, and be puzzled about whether it's be different in any other ways.

That said, I hope `O_DIRECTORY|O_CREAT` passes. I agree with Brauner that given that no regressions have appeared when changing to EINVAL means that there are no existing users, and that means EINVAL could be backported to all LTS kernels, thus resulting in either correct behavior or an error, but not incorrect behavior.

It'd be interesting to know what the BSDs and other FOSS Unix systems do with this combination.

How about O_CREAT_DIRECTORY?

Posted Jul 30, 2026 21:15 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

Quoting the previous LWN article (referenced in the article), these are the behavior of the BSDs:

> Falcato did some research on what other systems do in response to that combination of flags. NetBSD, it seems, will simply fail an open() call in that situation, returning EINVAL. FreeBSD, instead, will allow the call to succeed if the path exists and is a directory; otherwise it will fail. He also noted that all of the behaviors seen — Linux pre- and post-5.7, NetBSD, and FreeBSD — are allowed by POSIX: ""I would not call the old Linux behavior a *bug*, just really odd semantics"".

(And unrelated, but as a comment to the last sentence from Falcato above):

FWIW, "really odd semantics" are a bug, IMO. A bug that conforms to POSIX is still a bug.

How about O_CREAT_DIRECTORY?

Posted Jul 31, 2026 6:17 UTC (Fri) by lmartelli (subscriber, #11755) [Link] (6 responses)

It makes me wonder why did they choose O_DIRECTORY rather than O_DIR ?

How about O_CREAT_DIRECTORY?

Posted Jul 31, 2026 8:12 UTC (Fri) by pm215 (subscriber, #98099) [Link] (5 responses)

O_DIRECTORY is a much later addition, and presumably done when there was much less cultural pressure towards abbreviations in naming. In 7th edition unix the only valid mode flags were 0, 1 and 2 for read, write and readwrite, and the manpage documents them as magic numbers without any named symbols provided. By 2.10BSD the O_ names have been defined, but O_DIRECTORY is not yet among them, and it's not in 4.4BSD either.

How about O_CREAT_DIRECTORY?

Posted Jul 31, 2026 18:35 UTC (Fri) by huntermatthews (subscriber, #4490) [Link] (4 responses)

It wasn't _just_ cultural pressure - some early linkers had a 6 char limit. "O_CREAT" is 6 chars. My memory says the linker only cared that the first 6 chars were unique and you could have identifiers longer than that - but maybe that was a half way mark?

My understanding is that this was corrected or worked around by the late 70's.

HOWEVER, I was still dealing with scientific software in C in the mid 00's that had broken six char clean C pre-processor macros.
The answer was to turn them all off, but thats a different issue.

How about O_CREAT_DIRECTORY?

Posted Jul 31, 2026 19:48 UTC (Fri) by farnz (subscriber, #17727) [Link]

My understanding is that this all comes down to IBM SQUOZE and DEC RADIX 50 (and I suspect that DEC RADIX 50 was what influenced early UNIX, since it started on a PDP-7, an 18-bit DEC machine).

Those encodings get you 6 characters and a few flag bits in two 18-bit machine words, which is useful for both linkers and preprocessors alike; they were commonly used on the PDP-7 (and a slight variant on 16-bit minis like the PDP-11) for linkers, and almost certainly explain where the 6 significant character limit comes from - you squish the first 6 characters into a fixed 32 bit (on PDP-11) or 36-bit (on PDP-7) word, making lookup etc much simpler.

How about O_CREAT_DIRECTORY?

Posted Jul 31, 2026 23:45 UTC (Fri) by pm215 (subscriber, #98099) [Link] (1 responses)

O_CREAT is seven chars :) It also didn't arrive until 2.10BSD or so, which also added longer identifiers like O_APPEND and O_RDONLY. It's obviously named for the older creat() syscall.

For that matter, creat is also not six characters. Even back in the PDP-7 Unix that is as early as the tuhs website has, there are some six character syscall names, like rename. The linker being used on that PDP-7 seems to have had a "truncates to 8 chars" limit, as symbols like ttyrestart come out as ttyresta in the linker map; the convention seems to have been a leading '.' on syscall entrypoints, but that still leaves 7 chars. So it seems to me that while you're right that some older systems definitely did have very short limits, at the point when Thompson and Ritchie were defining unix syscall names, the choice of "creat" over "create" was not imposed by a technical limit but was rather "we like and are used to abbreviated names".

How about O_CREAT_DIRECTORY?

Posted Aug 3, 2026 7:45 UTC (Mon) by anselm (subscriber, #2796) [Link]

at the point when Thompson and Ritchie were defining unix syscall names, the choice of "creat" over "create" was not imposed by a technical limit but was rather "we like and are used to abbreviated names".

Remember that these are the folks who brought you ls, cp, and rm. If all you have to interact with your computer is an actual teletype (with a roll of paper rather than a CRT display), brevity becomes very enticing.

Also, people were presumably used to the idea of identifiers with at most six significant characters from Fortran.

How about O_CREAT_DIRECTORY?

Posted Aug 4, 2026 12:49 UTC (Tue) by dankamongmen (subscriber, #35141) [Link]

how is a linker implementation detail relevant for a macro? O_CREAT is not an object symbol.