Question about mkdir and ENOENT

[Tom Ridge]

Dear List,

Two errors during path resolution are ENOENT and ENOTDIR. Intuitively
ENOENT arises for paths such as /a/b/c, where there is no file b.
ENOTDIR arises when there is a file b, but it is not a directory.

Looking at the specification for link, rename and other commands, the
specification is consistent with this intuition.

However, looking at mkdir, we have:

[ENOENT]
A component of the path prefix specified by path does not name an
existing directory or path is an empty string.

This seems to say that for mkdir, an ENOENT is allowed for a path
/a/b/c, where b exists and is a non-directory file. This runs against
the intuition and the behaviour of the other commands. Is this
intended?

For reference, the typical phrasing of the ENOENT clause (eg with link
command) is:

[ENOENT]
A component of either path prefix does not exist; the file named by
path1 does not exist; or path1 or path2 points to an empty string.

Thanks

[Geoff Clare]

Post by Tom Ridge
Dear List,
Two errors during path resolution are ENOENT and ENOTDIR. Intuitively
ENOENT arises for paths such as /a/b/c, where there is no file b.
ENOTDIR arises when there is a file b, but it is not a directory.
Looking at the specification for link, rename and other commands, the
specification is consistent with this intuition.
[ENOENT]
A component of the path prefix specified by path does not name an
existing directory or path is an empty string.
This seems to say that for mkdir, an ENOENT is allowed for a path
/a/b/c, where b exists and is a non-directory file. This runs against
the intuition and the behaviour of the other commands. Is this
intended?

No, it looks like this is a case that we overlooked in bug 146.
That was more about trailing slashes when creating non-directory
files, but as part of it we changed the ENOENT wording for mkfifo()
and mknod() from "does not name an existing directory" to "does not
name an existing file". We should have done the same to mkdir().

[Tom Ridge]

Thanks for this clarification.

Was it ever considered to try and specify path resolution separately
from the individual commands such as link, mkdir etc? It seems that
the specification of path resolution (and errors that arise) is spread
across the many pages of the individual commands, often involving many
blocks of similar or identical text, and that keeping these all
consistent is a difficult task.

Post by Geoff Clare

Post by Tom Ridge
Dear List,
Two errors during path resolution are ENOENT and ENOTDIR. Intuitively
ENOENT arises for paths such as /a/b/c, where there is no file b.
ENOTDIR arises when there is a file b, but it is not a directory.
Looking at the specification for link, rename and other commands, the
specification is consistent with this intuition.
[ENOENT]
A component of the path prefix specified by path does not name an
existing directory or path is an empty string.
This seems to say that for mkdir, an ENOENT is allowed for a path
/a/b/c, where b exists and is a non-directory file. This runs against
the intuition and the behaviour of the other commands. Is this
intended?

No, it looks like this is a case that we overlooked in bug 146.
That was more about trailing slashes when creating non-directory
files, but as part of it we changed the ENOENT wording for mkfifo()
and mknod() from "does not name an existing directory" to "does not
name an existing file". We should have done the same to mkdir().
--
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England