bug#30350: 27.0.50; Newest master can't run processes on macOS

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp]

For some reason the newest master can't seem to start subprocesses on
macOS:

emacs -batch -Q --eval='(call-process "/usr/bin/true")'
Searching for program: Is a directory, /usr/bin/true

Needless to say, /usr/bin/true is a regular file.


In GNU Emacs 27.0.50 (build 40, x86_64-apple-darwin17.4.0, NS appkit-1561.20 Version 10.13.3 (Build 17D47))
 of 2018-02-04 built on p
Windowing system distributor 'Apple', version 10.3.1561
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --without-pop --with-mailutils
 --enable-gcc-warnings=yes --enable-checking
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS
JSON

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 204833 6997)
 (symbols 48 20086 1)
 (miscs 40 56 123)
 (strings 32 28886 1866)
 (string-bytes 1 771535)
 (vectors 16 35247)
 (vector-slots 8 721894 13798)
 (floats 8 52 64)
 (intervals 56 205 0)
 (buffers 992 11))

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Philipp <p.stephani2@gmail.com> schrieb am So., 4. Feb. 2018 um 21:17 Uhr:

>
> For some reason the newest master can't seem to start subprocesses on
> macOS:
>
> emacs -batch -Q --eval='(call-process "/usr/bin/true")'
> Searching for program: Is a directory, /usr/bin/true
>
> Needless to say, /usr/bin/true is a regular file.
>
>
According to 'git bisect', the problematic commit is

commit 327d251f8a857350a78029c31c7ab3f9797cc727

Author: Paul Eggert <eggert@cs.ucla.edu>

Date:   Sat Feb 3 12:10:19 2018 -0800


    Avoid EOVERFLOW problems with file-directory-p

[-- Attachment #2: Type: text/html, Size: 1369 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Eli Zaretskii]

> From: Philipp <p.stephani2@gmail.com>
> Date: Sun, 04 Feb 2018 21:15:56 +0100
> 
> For some reason the newest master can't seem to start subprocesses on
> macOS:
> 
> emacs -batch -Q --eval='(call-process "/usr/bin/true")'
> Searching for program: Is a directory, /usr/bin/true
> 
> Needless to say, /usr/bin/true is a regular file.

Try reverting 327d251.

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Sun, Feb 04, 2018 at 08:20:48PM +0000, Philipp Stephani wrote:
> Philipp <p.stephani2@gmail.com> schrieb am So., 4. Feb. 2018 um 21:17 Uhr:
> 
> >
> > For some reason the newest master can't seem to start subprocesses on
> > macOS:
> >
> > emacs -batch -Q --eval='(call-process "/usr/bin/true")'
> > Searching for program: Is a directory, /usr/bin/true
> >
> > Needless to say, /usr/bin/true is a regular file.
> >
> >
> According to 'git bisect', the problematic commit is
> 
> commit 327d251f8a857350a78029c31c7ab3f9797cc727
> 
> Author: Paul Eggert <eggert@cs.ucla.edu>
> 
> Date:   Sat Feb 3 12:10:19 2018 -0800
> 
> 
>     Avoid EOVERFLOW problems with file-directory-p

Oddly if you do

    (file-accessible-directory-p "/usr/bin/true")

it works correctly, but then once you run

    (call-process "/usr/bin/true")

file-accessible-directory-p incorrectly returns true on subsequent
calls. Paul’s commit didn’t make any real changes to
file-accessible-directory-p so I suspect this problem is older.

Incidentally it looks like, on MSDOS, file_directory_p calls
file_accessible_directory_p, which calls file_directory_p.
-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Sun, Feb 04, 2018 at 09:06:15PM +0000, Alan Third wrote:
> Oddly if you do
> 
>     (file-accessible-directory-p "/usr/bin/true")
> 
> it works correctly, but then once you run
> 
>     (call-process "/usr/bin/true")
> 
> file-accessible-directory-p incorrectly returns true on subsequent
> calls. Paul’s commit didn’t make any real changes to
> file-accessible-directory-p so I suspect this problem is older.

In fact, I can replicate it on Emacs 25, so it’s an old bug.
-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Alan Third <alan@idiocy.org> schrieb am So., 4. Feb. 2018 um 22:12 Uhr:

> On Sun, Feb 04, 2018 at 09:06:15PM +0000, Alan Third wrote:
> > Oddly if you do
> >
> >     (file-accessible-directory-p "/usr/bin/true")
> >
> > it works correctly, but then once you run
> >
> >     (call-process "/usr/bin/true")
> >
> > file-accessible-directory-p incorrectly returns true on subsequent
> > calls. Paul’s commit didn’t make any real changes to
> > file-accessible-directory-p so I suspect this problem is older.
>
> In fact, I can replicate it on Emacs 25, so it’s an old bug.
>
>
This is then a different bug; could you report it as a new one?

[-- Attachment #2: Type: text/html, Size: 1018 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Sun, Feb 04, 2018 at 09:28:12PM +0000, Philipp Stephani wrote:
> Alan Third <alan@idiocy.org> schrieb am So., 4. Feb. 2018 um 22:12 Uhr:
> 
> > On Sun, Feb 04, 2018 at 09:06:15PM +0000, Alan Third wrote:
> > > Oddly if you do
> > >
> > >     (file-accessible-directory-p "/usr/bin/true")
> > >
> > > it works correctly, but then once you run
> > >
> > >     (call-process "/usr/bin/true")
> > >
> > > file-accessible-directory-p incorrectly returns true on subsequent
> > > calls. Paul’s commit didn’t make any real changes to
> > > file-accessible-directory-p so I suspect this problem is older.
> >
> > In fact, I can replicate it on Emacs 25, so it’s an old bug.
> >
> >
> This is then a different bug; could you report it as a new one?

It’s actually all the same bug. Paul’s change made file-directory-p
use file-accessible-directory-p, and it’s playing up.

It looks like the root cause is faccessat returning 0 for
‘/usr/bin/true/.’ when it should probably be returning -1.
-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Alan Third <alan@idiocy.org> schrieb am So., 4. Feb. 2018 um 23:49 Uhr:

> On Sun, Feb 04, 2018 at 09:28:12PM +0000, Philipp Stephani wrote:
> > Alan Third <alan@idiocy.org> schrieb am So., 4. Feb. 2018 um 22:12 Uhr:
> >
> > > On Sun, Feb 04, 2018 at 09:06:15PM +0000, Alan Third wrote:
> > > > Oddly if you do
> > > >
> > > >     (file-accessible-directory-p "/usr/bin/true")
> > > >
> > > > it works correctly, but then once you run
> > > >
> > > >     (call-process "/usr/bin/true")
> > > >
> > > > file-accessible-directory-p incorrectly returns true on subsequent
> > > > calls. Paul’s commit didn’t make any real changes to
> > > > file-accessible-directory-p so I suspect this problem is older.
> > >
> > > In fact, I can replicate it on Emacs 25, so it’s an old bug.
> > >
> > >
> > This is then a different bug; could you report it as a new one?
>
> It’s actually all the same bug. Paul’s change made file-directory-p
> use file-accessible-directory-p, and it’s playing up.
>
> It looks like the root cause is faccessat returning 0 for
> ‘/usr/bin/true/.’ when it should probably be returning -1.
>
>
Good catch! Probably the bug was then introduced in 2012 with commit
73dcdb9f30cb94a3183db54d9b463370c3978d4d.

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

Does the attached patch work around the macOS bug? (I don't use macOS so 
can't easily test this.) The idea of this patch is to fix both the new 
bug with file-directory-p and the circa-2012 bug with 
file-accessible-directory-p.

The bug should probably be fixed in Gnulib so that Emacs proper is 
unaffected, but first I want to check whether this fix approach works.


[-- Attachment #2: fileio.diff --]
[-- Type: text/x-patch, Size: 1010 bytes --]

diff --git a/src/fileio.c b/src/fileio.c
index be29e60fc0..b0ef3d4e91 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -2811,12 +2811,15 @@ file_accessible_directory_p (Lisp_Object file)
     dir = data;
   else
     {
-      /* Just check for trailing '/' when deciding whether to append '/'.
-	 That's simpler than testing the two special cases "/" and "//",
-	 and it's a safe optimization here.  */
-      char *buf = SAFE_ALLOCA (len + 3);
+      /* Just check for trailing '/' when deciding whether append '/'
+	 before appending '.'.  That's simpler than testing the two
+	 special cases "/" and "//", and it's a safe optimization
+	 here.  After appending '.', append another '/' to work around
+	 a macOS bug (Bug#30350).  */
+      static char const appended[] = "/./";
+      char *buf = SAFE_ALLOCA (len + sizeof appended);
       memcpy (buf, data, len);
-      strcpy (buf + len, &"/."[data[len - 1] == '/']);
+      strcpy (buf + len, &appended[data[len - 1] == '/']);
       dir = buf;
     }
 

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Mon, Feb 05, 2018 at 11:13:16AM -0800, Paul Eggert wrote:
> Does the attached patch work around the macOS bug? (I don't use macOS so
> can't easily test this.) The idea of this patch is to fix both the new bug
> with file-directory-p and the circa-2012 bug with
> file-accessible-directory-p.

Yes, it fixes the problem here.

Is this a known issue with macOS?
-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

On 02/05/2018 11:18 AM, Alan Third wrote:
>
> Yes, it fixes the problem here.
>
> Is this a known issue with macOS?

It's news to me and it's not listed in the Gnulib portability gotcha list.

What happens if you run the attached program on macOS? It creates a file 
"file" and then tries to access it as a directory, which should not work.


[-- Attachment #2: tryit.c --]
[-- Type: text/x-csrc, Size: 740 bytes --]

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <errno.h>

static char const *names[] = { "file/", "file/.", "file/./" };

int
main (void)
{
  struct stat st;
  int i;
  if (open ("file", O_WRONLY | O_CREAT, 0666) < 0)
    return perror ("file"), 1;
  int status = 0;
  for (i = 0; i < 3; i++)
    {
      char const *name = names[i];
      if (lstat (name, &st) == 0)
	printf ("lstat succeeds on \"%s\"!\n", name), status = 1;
      else if (errno != ENOTDIR)
	perror (name), status = 1;
      if (faccessat (AT_FDCWD, name, F_OK, AT_EACCESS) == 0)
	printf ("faccessat succeeds on \"%s\"!\n", name), status = 1;
      else if (errno != ENOTDIR)
	perror (name), status = 1;
    }
  return status;
}

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Paul Eggert <eggert@cs.ucla.edu> schrieb am Di., 6. Feb. 2018 um 00:56 Uhr:

> On 02/05/2018 11:18 AM, Alan Third wrote:
> >
> > Yes, it fixes the problem here.
> >
> > Is this a known issue with macOS?
>
> It's news to me and it's not listed in the Gnulib portability gotcha list.
>
> What happens if you run the attached program on macOS? It creates a file
> "file" and then tries to access it as a directory, which should not work.
>
>
It succeeds and prints nothing (i.e. the error is ENOTDIR in all cases).
So this is even more mysterious than I thought.

[-- Attachment #2: Type: text/html, Size: 906 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Paul Eggert]

On 02/05/2018 04:26 PM, Philipp Stephani wrote:
> It succeeds and prints nothing (i.e. the error is ENOTDIR in all cases).
> So this is even more mysterious than I thought.

Very strange. I installed the workaround into Emacs master, so at least 
the symptoms should be fixed now. But I don't know why the fix worked, 
and this doesn't inspire warm feelings.

The Gnulib manual says that macOS faccessat (..., "FILE/", ...) 
incorrectly succeeds when FILE is a regular file, and Gnulib has code to 
work around that bug that should be in effect for Emacs. However, the 
Gnulib manual doesn't say that faccessat (..., "FILE/.", ...) 
incorrectly succeeds in this situation, nor that faccessat (..., 
"FILE/./", ...) does the right thing; and the test program I gave you 
didn't illustrate any bugs in this area so I'm not sure what's going on.

It may require digging around in the FreeBSD source code to puzzle this 
one out, assuming FreeBSD has the same bug that macOS does.

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Paul Eggert <eggert@cs.ucla.edu> schrieb am Di., 6. Feb. 2018 um 01:36 Uhr:

> On 02/05/2018 04:26 PM, Philipp Stephani wrote:
> > It succeeds and prints nothing (i.e. the error is ENOTDIR in all cases).
> > So this is even more mysterious than I thought.
>
> Very strange. I installed the workaround into Emacs master, so at least
> the symptoms should be fixed now. But I don't know why the fix worked,
> and this doesn't inspire warm feelings.
>
> The Gnulib manual says that macOS faccessat (..., "FILE/", ...)
> incorrectly succeeds when FILE is a regular file, and Gnulib has code to
> work around that bug that should be in effect for Emacs. However, the
> Gnulib manual doesn't say that faccessat (..., "FILE/.", ...)
> incorrectly succeeds in this situation, nor that faccessat (...,
> "FILE/./", ...) does the right thing; and the test program I gave you
> didn't illustrate any bugs in this area so I'm not sure what's going on.
>

Maybe that bug was once present, and has been fixed since then?
I've noticed that REPLACE_FACCESSAT is 1, so configure thinks that
faccessat is broken. Apparently faccessat.m4 checks for the behavior of
lstat, not faccessat.

[-- Attachment #2: Type: text/html, Size: 1558 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Mon, Feb 05, 2018 at 04:36:13PM -0800, Paul Eggert wrote:
> The Gnulib manual says that macOS faccessat (..., "FILE/", ...) incorrectly
> succeeds when FILE is a regular file, and Gnulib has code to work around
> that bug that should be in effect for Emacs. However, the Gnulib manual
> doesn't say that faccessat (..., "FILE/.", ...) incorrectly succeeds in this
> situation, nor that faccessat (..., "FILE/./", ...) does the right thing;
> and the test program I gave you didn't illustrate any bugs in this area so
> I'm not sure what's going on.

Bear in mind that file-accessible-directory-p works prior to
call-process being run. Call-process does something that breaks it.

Interestingly it breaks file-accessible-directory-p for *all* files in
the same directory, so

    (call-process "/usr/bin/true")
    (file-accessible-directory-p "/usr/bin/false")

fails, while

    (call-process "/usr/bin/true")
    (file-accessible-directory-p "/bin/zsh")

works correctly. (Well, call-process itself fails, but
file-accessible-directory-p works.)

I haven’t been able to work out what it is that call-process is doing
that causes this.

-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 6. Feb. 2018 um
01:26 Uhr:

> Paul Eggert <eggert@cs.ucla.edu> schrieb am Di., 6. Feb. 2018 um
> 00:56 Uhr:
>
>> On 02/05/2018 11:18 AM, Alan Third wrote:
>> >
>> > Yes, it fixes the problem here.
>> >
>> > Is this a known issue with macOS?
>>
>> It's news to me and it's not listed in the Gnulib portability gotcha list.
>>
>> What happens if you run the attached program on macOS? It creates a file
>> "file" and then tries to access it as a directory, which should not work.
>>
>>
> It succeeds and prints nothing (i.e. the error is ENOTDIR in all cases).
> So this is even more mysterious than I thought.
>

However, when I change "file" to "/usr/bin/true" in the names list, the
issue happens again (i.e. lstat and faccessat succeed for
"/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
consistently reproducible.

[-- Attachment #2: Type: text/html, Size: 1591 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 6. Feb. 2018 um
23:07 Uhr:

> Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 6. Feb. 2018 um
> 01:26 Uhr:
>
>> Paul Eggert <eggert@cs.ucla.edu> schrieb am Di., 6. Feb. 2018 um
>> 00:56 Uhr:
>>
>>> On 02/05/2018 11:18 AM, Alan Third wrote:
>>> >
>>> > Yes, it fixes the problem here.
>>> >
>>> > Is this a known issue with macOS?
>>>
>>> It's news to me and it's not listed in the Gnulib portability gotcha
>>> list.
>>>
>>> What happens if you run the attached program on macOS? It creates a file
>>> "file" and then tries to access it as a directory, which should not work.
>>>
>>>
>> It succeeds and prints nothing (i.e. the error is ENOTDIR in all cases).
>> So this is even more mysterious than I thought.
>>
>
> However, when I change "file" to "/usr/bin/true" in the names list, the
> issue happens again (i.e. lstat and faccessat succeed for
> "/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
> consistently reproducible.
>

The issue also goes away if I change the fourth argument of faccessat to 0.

[-- Attachment #2: Type: text/html, Size: 2083 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Tue, Feb 06, 2018 at 10:07:52PM +0000, Philipp Stephani wrote:
> However, when I change "file" to "/usr/bin/true" in the names list, the
> issue happens again (i.e. lstat and faccessat succeed for
> "/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
> consistently reproducible.

Try setting the permissions of the test file to 500.

It looks like if the file is only readable and executable, then the
problem occurs, but if it’s writable it goes away.

That’s why we see it in places like /usr/bin where we don’t have write
permission, but can’t reproduce it in ~/ where we do.
-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Noam Postavsky]

On Tue, Feb 6, 2018 at 5:44 PM, Alan Third <alan@idiocy.org> wrote:
> On Tue, Feb 06, 2018 at 10:07:52PM +0000, Philipp Stephani wrote:
>> However, when I change "file" to "/usr/bin/true" in the names list, the
>> issue happens again (i.e. lstat and faccessat succeed for
>> "/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
>> consistently reproducible.
>
> Try setting the permissions of the test file to 500.
>
> It looks like if the file is only readable and executable, then the
> problem occurs, but if it’s writable it goes away.
>
> That’s why we see it in places like /usr/bin where we don’t have write
> permission, but can’t reproduce it in ~/ where we do.

Is this the same or related to Bug#21573? (I don't know much about
macOS, but seems to involve the same system call)

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Paul Eggert]

On 02/05/2018 04:43 PM, Philipp Stephani wrote:
> Maybe that bug was once present, and has been fixed since then?
> I've noticed that REPLACE_FACCESSAT is 1, so configure thinks that 
> faccessat is broken. Apparently faccessat.m4 checks for the behavior 
> of lstat, not faccessat.

My impression is that the Gnulib manual section was written at the same 
time as the REPLACE_FACCESSAT stuff. The code assumes that faccessat is 
broken only if lstat is broken is a similar way. My guess is that this 
new behavior (whatever it is) is a somewhat-different bug.

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Eli Zaretskii]

> Date: Sun, 4 Feb 2018 21:06:15 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 30350@debbugs.gnu.org
> 
> Incidentally it looks like, on MSDOS, file_directory_p calls
> file_accessible_directory_p, which calls file_directory_p.

Thanks for catching this, I fixed it now.

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 6. Feb. 2018 um
23:10 Uhr:

> Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 6. Feb. 2018 um
> 23:07 Uhr:
>
>> Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 6. Feb. 2018 um
>> 01:26 Uhr:
>>
>>> Paul Eggert <eggert@cs.ucla.edu> schrieb am Di., 6. Feb. 2018 um
>>> 00:56 Uhr:
>>>
>>>> On 02/05/2018 11:18 AM, Alan Third wrote:
>>>> >
>>>> > Yes, it fixes the problem here.
>>>> >
>>>> > Is this a known issue with macOS?
>>>>
>>>> It's news to me and it's not listed in the Gnulib portability gotcha
>>>> list.
>>>>
>>>> What happens if you run the attached program on macOS? It creates a file
>>>> "file" and then tries to access it as a directory, which should not
>>>> work.
>>>>
>>>>
>>> It succeeds and prints nothing (i.e. the error is ENOTDIR in all cases).
>>> So this is even more mysterious than I thought.
>>>
>>
>> However, when I change "file" to "/usr/bin/true" in the names list, the
>> issue happens again (i.e. lstat and faccessat succeed for
>> "/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
>> consistently reproducible.
>>
>
> The issue also goes away if I change the fourth argument of faccessat to
> 0.
>


...albeit only temporarily. Occasionally the wrong behavior happens,
occasionally is doesn't, seemingly without meaningful pattern. This seems
to be quite a nasty bug in the OS.

[-- Attachment #2: Type: text/html, Size: 2700 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Alan Third <alan@idiocy.org> schrieb am Di., 6. Feb. 2018 um 23:44 Uhr:

> On Tue, Feb 06, 2018 at 10:07:52PM +0000, Philipp Stephani wrote:
> > However, when I change "file" to "/usr/bin/true" in the names list, the
> > issue happens again (i.e. lstat and faccessat succeed for
> > "/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
> > consistently reproducible.
>
> Try setting the permissions of the test file to 500.
>
> It looks like if the file is only readable and executable, then the
> problem occurs, but if it’s writable it goes away.
>
> That’s why we see it in places like /usr/bin where we don’t have write
> permission, but can’t reproduce it in ~/ where we do.
>
>
Hmm. Using the sequence {"file", "file/."} with a mode of 0777 in /tmp
indeed triggers the wrong behavior for me.

[-- Attachment #2: Type: text/html, Size: 1202 bytes --]

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Alan Third]

On Sun, Feb 11, 2018 at 04:01:18PM +0000, Philipp Stephani wrote:
> Alan Third <alan@idiocy.org> schrieb am Di., 6. Feb. 2018 um 23:44 Uhr:
> 
> > On Tue, Feb 06, 2018 at 10:07:52PM +0000, Philipp Stephani wrote:
> > > However, when I change "file" to "/usr/bin/true" in the names list, the
> > > issue happens again (i.e. lstat and faccessat succeed for
> > > "/usr/bin/true/."). So this does appear to be a macOS bug, but it's not
> > > consistently reproducible.
> >
> > Try setting the permissions of the test file to 500.
> >
> > It looks like if the file is only readable and executable, then the
> > problem occurs, but if it’s writable it goes away.
> >
> > That’s why we see it in places like /usr/bin where we don’t have write
> > permission, but can’t reproduce it in ~/ where we do.
> >
> >
> Hmm. Using the sequence {"file", "file/."} with a mode of 0777 in /tmp
> indeed triggers the wrong behavior for me.

Oh well. As you said, then: It’s inconsistent.
-- 
Alan Third

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

>> Hmm. Using the sequence {"file", "file/."} with a mode of 0777 in /tmp
>> indeed triggers the wrong behavior for me.
>
> Oh well. As you said, then: It’s inconsistent.

Paul committed some changes to work around the problems described in
this bug report, but it's unclear whether there's anything more to do
here.  Should this bug report be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#30350: 27.0.50; Newest master can't run processes on macOS

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Alan Third <alan@idiocy.org> writes:
>
>>> Hmm. Using the sequence {"file", "file/."} with a mode of 0777 in /tmp
>>> indeed triggers the wrong behavior for me.
>>
>> Oh well. As you said, then: It’s inconsistent.
>
> Paul committed some changes to work around the problems described in
> this bug report, but it's unclear whether there's anything more to do
> here.  Should this bug report be closed?

There was no response in six weeks, so I'm going to go ahead and guess
that this problem has been fixed now (especially since I can't reproduce
it).  If this is still a problem, please respond to the debbugs address
and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no