Re: Use current directory for POSIX mkdir test in install-sh

[Paul Eggert]

(This is following up to
<http://lists.gnu.org/archive/html/bug-autoconf/2006-10/msg00012.html>.
I'm CC:ing to bug-automake since install-sh belongs to Automake.)

"Alex Unleashed" <address@hidden> writes:

>> Sorry, but this fix causes install-sh to deduce the wrong
>> answer if the working directory is not searchable.
>
> Yes, you are right, and I didn't think about this possibility. However I
> just find it hard to imagine having such permissions when installing
> software. Is there any real world package running install-sh on such
> directories (maybe I'm missing something here)?

Sorry, I don't recall the details, but the usual problem is that
someone builds as an ordinary user and then installs as root under
NFS, and root has no permissions in the working directory.  In such an
environment "install-sh /a/b/c /d/e/f" would incorrectly fail if it
insisted on being able to search the working directory.  It is a bit
odd, admittedly.

> The difference with other mkdir versions is that GNU mkdir does not try to
> chmod() the directory if it didn't just create it. The mkdir I'm currently
> testing is FreeBSD's. It always chmod()'s the directory when a mode is
> specified, no matter it didn't create it.

Ouch!

That behavior is incorrect; it doesn't conform to POSIX.  You might
file a bug report, citing
<http://www.opengroup.org/onlinepubs/009695399/utilities/mkdir.html>.

This is the first I've heard of this bug, and the first step in
addressing it is to document it.  I installed the Autoconf patch
enclosed below.  I'll follow up with a proposed fix to install-sh
soon.

> This chmod(), even when failing,
> is considered an attempt to write to an external path,

That's weird.  mkdir("/", ...) is not considered to be an attempt to
write to an external file name, but chmod ("/", ...) is?  This doesn't
sound consistent to me; both system calls _attempt_ to write to an
external file name.  And neither _succeeds_ (which is what should
matter here).  So it sounds like your sandbox tests should be
adjusted, one way or another, since they're not consistent.

2006-10-09  Paul Eggert  <address@hidden>

        * doc/autoconf.texi (Limitations of Usual Tools): Describe
        problems with mkdir -p -m.

--- doc/autoconf.texi.~1.1090.~ 2006-10-06 09:45:32.000000000 -0700
+++ doc/autoconf.texi   2006-10-09 15:50:10.000000000 -0700
@@ -13476,6 +13476,13 @@ No @command{mkdir} option is portable to
 @code{AS_MKDIR_P(@var{file-name})} (@pxref{Programming in M4sh})
 or @code{AC_PROG_MKDIR_P} (@pxref{Particular Programs}).
 
+Combining the @option{-m} and @option{-p} options, as in @samp{mkdir -m
+go-w -p @var{dir}}, often leads to trouble.  address@hidden
address@hidden incorrectly attempts to change the permissions of
address@hidden even if it already exists.  @acronym{HP-UX} 11.23 and
address@hidden 6.5 @command{mkdir} often assign the wrong permissions to
+any newly-created parents of @var{dir}.
+
 Posix does not clearly specify whether @samp{mkdir -p foo}
 should succeed when @file{foo} is a symbolic link to an already-existing
 directory.  The @acronym{GNU} Core Utilities 5.1.0 @command{mkdir}