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.
