(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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> * 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. [EMAIL PROTECTED] [EMAIL PROTECTED] incorrectly attempts to change the permissions of [EMAIL PROTECTED] even if it already exists. @acronym{HP-UX} 11.23 and [EMAIL PROTECTED] 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}
