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

[Jonny Grant]

On 01/05/2020 19:07, Paul Eggert wrote:
> On 5/1/20 9:16 AM, Jonny Grant wrote:
> > rm: cannot remove 'test': Is a directory
>
> That's because rm used unlink which failed with EISDIR, which is a different
> error number.

yes, the fix pretty trivial for mkdir as you highlight EISDIR:
stat(), S_ISDIR(sb.st_mode), and set errno to EISDIR or output 
strerror(EISDIR)

$ mkdir test
mkdir: cannot create directory ‘test’: Is a directory

> Consider this example:
>
>      $ >d # Create an empty regular file.
>      $ mkdir d
>      mkdir: cannot create directory ‘d’: File exists
>
> Here the system call mkdir("d", 0777) failed with errno == EEXIST (File exists).
> Presumably you wouldn't object to the diagnostic here because d is a regular
> file, not a directory. But the mkdir system call fails in exactly the same way
> if d is a directory, so the error message is the same in both cases.

Exactly, UNIX didn't create separate errno for files and directories, 
it's the same limitation with ENOENT. As a developer, we handle it 
ourselves, as it's easy enough to call stat() like other package 
maintainers do, as you can see in binutils.

> Directories are files, so the error message is correct even if it confused you.
> I don't see any portable and efficient way to make the diagnostic less confusing
> for you, without also making diagnostic incorrect in some other scenarios (such
> as the scenario described above).

Feels like the fix I already proposed does not have any incorrect impact 
in the other scenario you describe? Do correct me if I am missing something.

Yes, as a developer I know everything is actually a file, but users 
don't. Users will call it a folder, or a directory. I didn't go over 
UNIX everything-is-a-file in my bug report because everyone here knows 
already.

This one is an simple fix, but it's clear no one wants to introduce the 
change, no worries.

Cheers, Jonny