bug#41001: mkdir: cannot create directory ‘test’: File exists

[Eric Blake]

On 5/7/20 6:29 AM, Jonny Grant wrote:

> > 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.
>
> Sounds good.
>
> Would that O_ flag work on the 'mode' ? in which case could be mkdir() too.

Bummer. I forgot that mkdirat() was one of the interfaces that lacks a 
separate flags parameter (I was thinking more about openat).

But ultimately, whether the kernel adds a mkdirat4(dirfd, name, mode, 
flags), or merely adds flags that can be OR'd in with mode, is up to the 
kernel folks.  You'll have to convince someone in the kernel that an 
extension to the existing interface is worthwhile.  Ruminating on what 
that extension might look like here on the coreutils list won't get it 
any closer to actually being implemented.

(My personal wish: I would love a variation of mkdir that returns an 
open fd on the just-created directory on success in a single syscall, 
instead of the current practice of having to pair mkdir()/open() - 
something that is also doable if you have a flags parameter to opt-in to 
that new behavior.)

> > 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.
>
> I doubt glibc would ever agree to change strerror(EEXIST). I imagine it 
> all gets beaurocratic, and they might require POSIX make the update to 
> the spec first?

POSIX does _not_ require that strerror(EEXIST) output "File exists", but 
merely that it represent _some_ error message about a directory entry 
already existing (most generically called a file, even when it is not a 
regular file).  I see no reason why glibc developers would be able to 
use POSIX as a reason why they could not change their output table.  But 
you are also right that they might have other arguments about why 
changing an output string is undesirable.  But to find out, you'll have 
to ask on the glibc list, not here.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org