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

[Philipp Stephani <p.stephani2@gmail.com>]

[-- 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 --]