GNU bug report logs - #30350
27.0.50; Newest master can't run processes on macOS

Previous Next

Full log

Message #82 received at 30350 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30350 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Tue, 06 Feb 2018 22:10:07 +0000

[Message part 1 (text/plain, inline)]

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

> Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 6. Feb. 2018 um
> 01:26 Uhr:
>
>> Paul Eggert <eggert <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.