On 5/5/20 1:36 PM, Jonny Grant wrote:
Okay. That's confusing. The only value in hand being EEXIST then
that is the error to be reported. If this were repeated many times
then sometimes we would catch it as an actual directory.
lstat("foodir1", 0x7ffcafc12800) = -1 ENOENT (No such file or
directory)
mkdir("foodir1", 0777) = -1 EEXIST (File exists)
lstat("foodir1", {st_mode=S_IFDIR|0775, st_size=40, ...}) = 0
In that case the proposal is to report it as EISDIR.
yes, I only asked Linux kernel ext4 team, as it is one place to ask the
question, and judge the response. They also don't want to make any
change. We're stuck with all these old interfaces. Unless someone wants
to come up with mkdir2() and get it into POSIX.
We already have mkdirat() specified by POSIX. It would be easier to add
a new O_ flag that tells mkdirat() to give a different errno failure
than to add a completely new interface. But emulating that new flag on
older kernels that don't natively support it will be back at the same
non-atomic racy situation we are in now.
Maybe a simple localised string is better in your mkdir tool? After-all
the man page and POSIX gives the exact meaning of EEXIST in this context?
"pathname already exists"
If you can convince glibc to change the contents of their
strerror(EEXIST) along those lines, then go for it. But they would
probably tell you that the GNU Coding Standards frown on using
"pathname" instead of "filename" (per GCS, "path" should be reserved for
colon-separated lists such as $PATH - which is a different definition
than POSIX has where "path" is merely a concatenation of "filenames"
using '/', so it's a tough sell.
The output is only incorrect because it defaults to system localised
strerror(EEXIST)
So with this change, it would be:
mkdir: cannot create directory ‘test’: pathname already exists
Giving different output than strerror() will confuse users; it's better
to make the change in glibc for ALL clients of strerror(EEXIST) rather
than just this one client.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org