Philipp Stephani schrieb am Di., 6. Feb. 2018 um 23:10 Uhr: > Philipp Stephani schrieb am Di., 6. Feb. 2018 um > 23:07 Uhr: > >> Philipp Stephani schrieb am Di., 6. Feb. 2018 um >> 01:26 Uhr: >> >>> Paul Eggert 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.