Re: mkdir -p and POSIX

[Jim Meyering]

Eric Blake wrote:
> The Austin Group made their recommendation about mkdir -p today:
>
> "I suggest replacing the description of -p with:
>
> -p  Create any missing intermediate pathname components.
>
>     For each dir operand that does not name an existing directory,
>     before performing the actions described in the DESCRIPTION above
>     the mkdir utility shall create any pathname components of the path
>     prefix of dir that do not name an existing directory by performing
>     actions equivalent to first calling the mkdir() function with the
>     following arguments:
>
>       1. A pathname naming the missing pathname component, ending
>          with a trailing <slash> character, as the path argument.
>
>       2. The value zero as the mode argument.
>
>     and then calling the chmod() function with the following
>     arguments:
>
>       1. The same path argument as in the mkdir() call.
>
>       2. The value (S_IWUSR|S_IXUSR|~filemask) as the mode argument,
>          where filemask is the file mode creation mask of the process
>          (see [xref to umask()]).
>
>     Each dir operand that names an existing directory shall be ignored
>     without error."
> http://austingroupbugs.net/view.php?id=161

Hmm... that URL is useful only if you have a login/password.
Imposing such restrictions just to view a thread seems
counterproductive.

> The significant part about this is that it requires, for 'mkdir -p a/b', that
> implementations call mkdir("a/",mode), not mkdir("a",mode).  This makes a
> difference, given that the POSIX requirements for mkdir(2) will follow through
> a dangling symlink "a" to create the underlying directory, where without the
> trailing slash it would fail with EEXIST.
>
> Should I go ahead and start modifying the mkdir-p module to preserve the
> trailing slash to the underlying mkdir call?  It won't immediately change

That sounds reasonable.
However, bear in mind (for down the road) that I am very leery
of interposing any symlink-traversing code to resolve this.

> behavior on GNU/Linux (without either a kernel change or an rpl_mkdir 
> wrapper),
> because GNU's behavior for mkdir("dangling/") is contrary to POSIX.  But it
> will make a difference on Solaris.
>
> This also means that build-aux/mkinstalldirs and build-aux/install-sh are also
> impacted.  And there, since we can't guarantee whether the system mkdir(1)
> gracefully handles trailing slashes, it could get rather difficult to 
> guarantee
> creating a directory tree through a dangling symlink using portable shell 
> code.