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




Reply via email to