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

Previous Next

Package: emacs;

Reported by: Philipp <p.stephani2 <at> gmail.com>

Date: Sun, 4 Feb 2018 20:17:02 UTC

Severity: normal

Merged with 30357

Found in version 27.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30350 in the body.
You can then email your comments to 30350 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 20:17:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Philipp <p.stephani2 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 04 Feb 2018 20:17:02 GMT) Full text and rfc822 format available.

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

From: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Newest master can't run processes on macOS
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.


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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 20:22:01 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 04 Feb 2018 20:20:48 +0000
[Message part 1 (text/plain, inline)]
Philipp <p.stephani2 <at> 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 <at> cs.ucla.edu>

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


    Avoid EOVERFLOW problems with file-directory-p
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 20:26:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 04 Feb 2018 22:24:56 +0200
> From: Philipp <p.stephani2 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 21:07:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 4 Feb 2018 21:06:15 +0000
On Sun, Feb 04, 2018 at 08:20:48PM +0000, Philipp Stephani wrote:
> Philipp <p.stephani2 <at> 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 <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 21:13:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 4 Feb 2018 21:12:24 +0000
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 21:29:02 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 04 Feb 2018 21:28:12 +0000
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> 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?
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 22:51:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 4 Feb 2018 22:49:56 +0000
On Sun, Feb 04, 2018 at 09:28:12PM +0000, Philipp Stephani wrote:
> Alan Third <alan <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 04 Feb 2018 23:17:02 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 04 Feb 2018 23:16:24 +0000
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> 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 <at> 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.
[Message part 2 (text/html, inline)]

Merged 30350 30357. Request was from Noam Postavsky <npostavs <at> users.sourceforge.net> to control <at> debbugs.gnu.org. (Mon, 05 Feb 2018 14:26:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Mon, 05 Feb 2018 19:14:01 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Sam Steingold <sds <at> podval.org>, Alan Third <alan <at> idiocy.org>
Subject: Re: 27.0.50; Newest master can't run processes on macOS
Date: Mon, 5 Feb 2018 11:13:16 -0800
[Message part 1 (text/plain, inline)]
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.

[fileio.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Mon, 05 Feb 2018 19:19:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30350 <at> debbugs.gnu.org, Philipp <p.stephani2 <at> gmail.com>,
 Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Mon, 5 Feb 2018 19:18:24 +0000
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Mon, 05 Feb 2018 23:57:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, Philipp <p.stephani2 <at> gmail.com>,
 Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Mon, 5 Feb 2018 15:56:52 -0800
[Message part 1 (text/plain, inline)]
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.

[tryit.c (text/x-csrc, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 00:27:02 GMT) Full text and rfc822 format available.

Message #40 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 00:26:04 +0000
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 00:37:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
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: Mon, 5 Feb 2018 16:36:13 -0800
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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 00:44:02 GMT) Full text and rfc822 format available.

Message #46 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 00:43:35 +0000
[Message part 1 (text/plain, inline)]
Paul Eggert <eggert <at> 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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 08:29:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Tue, 6 Feb 2018 08:28:41 +0000
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 15:28:02 GMT) Full text and rfc822 format available.

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

From: Mikhail Gusarov <dottedmag <at> dottedmag.net>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 16:27:40 +0100
[Message part 1 (text/plain, inline)]
Hi.

On Tue, 6 Feb 2018, at 09:08, Philipp Stephani wrote:
>> I see a breakage of Emacs build on master under MacOS 10.13. Build
>> stops with the following message:>> 
>> org/org-timer.el:39:1:Error: Searching for program: Is a directory,
>> /bin/zsh>> 
>> The file in question is not a directory:
>> 
>> % ls -l /bin/zsh
>> 404K -rwxr-xr-x 1 root wheel 596K
> This is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30350.

Yes, it is. I can't find the relevant sources right away, but opening a
file inside a file is a syntax for opening  resource forks under OS X,
so `/foo/bar/baz/.` is a "directory" of resource forks there. This
syntax is not likely to go away anytime soon.
Mikhail.

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 18:57:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mikhail Gusarov <dottedmag <at> dottedmag.net>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 6 Feb 2018 18:56:10 +0000
On Tue, Feb 06, 2018 at 04:27:40PM +0100, Mikhail Gusarov wrote:
> Yes, it is. I can't find the relevant sources right away, but opening a
> file inside a file is a syntax for opening  resource forks under OS X,
> so `/foo/bar/baz/.` is a "directory" of resource forks there. This
> syntax is not likely to go away anytime soon.

Hmm, perhaps this method of checking for a directory just won’t ever
work reliably on macOS then.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:15:02 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Mikhail Gusarov <dottedmag <at> dottedmag.net>
Cc: 30350 <at> debbugs.gnu.org
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 21:14:26 +0000
[Message part 1 (text/plain, inline)]
Mikhail Gusarov <dottedmag <at> dottedmag.net> schrieb am Di., 6. Feb. 2018 um
16:28 Uhr:

> Hi.
>
> On Tue, 6 Feb 2018, at 09:08, Philipp Stephani wrote:
>
> I see a breakage of Emacs build on master under MacOS 10.13. Build stops
> with the following message:
>
> org/org-timer.el:39:1:Error: Searching for program: Is a directory,
> /bin/zsh
>
> The file in question is not a directory:
>
> % ls -l /bin/zsh
> 404K -rwxr-xr-x 1 root wheel 596K
>
> This is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30350.
>
>
> Yes, it is. I can't find the relevant sources right away, but opening a
> file inside a file is a syntax for opening resource forks under OS X, so
> `/foo/bar/baz/.` is a "directory" of resource forks there. This syntax is
> not likely to go away anytime soon.
>
>
It's true that you can access the forks in a pseudo-directory
/foo/bar/baz/..namedforks/, but faccessat still seems to work correctly
even for files containing resource forks, at least on my system. That is,
the POSIX API doesn't actually treat /foo/bar/baz/. as a directory.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:16:02 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Mikhail Gusarov <dottedmag <at> dottedmag.net>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 21:15:32 +0000
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> schrieb am Di., 6. Feb. 2018 um 19:56 Uhr:

> On Tue, Feb 06, 2018 at 04:27:40PM +0100, Mikhail Gusarov wrote:
> > Yes, it is. I can't find the relevant sources right away, but opening a
> > file inside a file is a syntax for opening  resource forks under OS X,
> > so `/foo/bar/baz/.` is a "directory" of resource forks there. This
> > syntax is not likely to go away anytime soon.
>
> Hmm, perhaps this method of checking for a directory just won’t ever
> work reliably on macOS then.
>
>
But it works reliable in all isolated test cases that I've tried. Only the
combination with call-process seems to cause issues for some weird reason.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:24:02 GMT) Full text and rfc822 format available.

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

From: "John Wiegley" <johnw <at> gnu.org>
To: Mikhail Gusarov <dottedmag <at> dottedmag.net>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 09:40:30 -0800
>>>>> "MG" == Mikhail Gusarov <dottedmag <at> dottedmag.net> writes:

MG>         org/org-timer.el:39:1:Error: Searching for program: Is a
MG> directory, /bin/zsh

MG>         The file in question is not a directory:

MG> Yes, it is. I can't find the relevant sources right away, but opening a
MG> file inside a file is a syntax for opening resource forks under OS X, so
MG> `/foo/bar/baz/.` is a "directory" of resource forks there. This syntax is
MG> not likely to go away anytime soon.

Mikhail, are you saying that "/bin/zsh", where /bin/zsh is a file, should
report as a directory on OS X? I think I've misunderstood your comment.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:27:01 GMT) Full text and rfc822 format available.

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

From: Mikhail Gusarov <dottedmag <at> dottedmag.net>
To: John Wiegley <johnw <at> gnu.org>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 22:26:00 +0100
Hi John,

On Tue, 6 Feb 2018, at 18:40, John Wiegley wrote:

> Mikhail, are you saying that "/bin/zsh", where /bin/zsh is a file, should
> report as a directory on OS X? I think I've misunderstood your comment.

I'm saying that on OS X stat'ing /bin/zsh and /bin/zsh/ (or /bin/zsh/.) gives different results:

% stat /bin/zsh
16777220 721698 -rwxr-xr-x 1 root wheel 0 610288 "Feb  6 22:24:24 2018" "Sep 21 06:35:23 2017" "Nov  6 13:34:29 2017" "Sep 21 06:35:23 2017" 4194304 808 0x80020 /bin/zsh
% stat /bin/zsh/.
stat: /bin/zsh/.: stat: Not a directory
% stat /bin/zsh/
stat: /bin/zsh/: stat: Not a directory
%




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:30:02 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Mikhail Gusarov <dottedmag <at> dottedmag.net>
Cc: 30350 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 21:29:40 +0000
[Message part 1 (text/plain, inline)]
Mikhail Gusarov <dottedmag <at> dottedmag.net> schrieb am Di., 6. Feb. 2018 um
22:26 Uhr:

> Hi John,
>
> On Tue, 6 Feb 2018, at 18:40, John Wiegley wrote:
>
> > Mikhail, are you saying that "/bin/zsh", where /bin/zsh is a file, should
> > report as a directory on OS X? I think I've misunderstood your comment.
>
> I'm saying that on OS X stat'ing /bin/zsh and /bin/zsh/ (or /bin/zsh/.)
> gives different results:
>
> % stat /bin/zsh
> 16777220 721698 -rwxr-xr-x 1 root wheel 0 610288 <06102%2088> "Feb  6
> 22:24:24 2018" "Sep 21 06:35:23 2017" "Nov  6 13:34:29 2017" "Sep 21
> 06:35:23 2017" 4194304 808 0x80020 /bin/zsh
> % stat /bin/zsh/.
> stat: /bin/zsh/.: stat: Not a directory
> % stat /bin/zsh/
> stat: /bin/zsh/: stat: Not a directory
> %
>

That's the behavior required by POSIX, and Linux behaves in exactly the
same way, so it's not something where we'd need to special-case macOS.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:31:01 GMT) Full text and rfc822 format available.

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

From: Mikhail Gusarov <dottedmag <at> dottedmag.net>
To: John Wiegley <johnw <at> gnu.org>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 22:30:19 +0100
On Tue, 6 Feb 2018, at 22:26, Mikhail Gusarov wrote:

> I'm saying that on OS X stat'ing /bin/zsh and /bin/zsh/ (or /bin/zsh/.) 
> gives different results:

And here is a test program and its output:

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

static void teststat(const char *filename)
{
    struct stat st;
    errno = 0;
    int res = stat(filename, &st);
    printf("%s stat->%d errno->%d\n", filename, res, errno);
}

int main()
{
    teststat("/bin/zsh");
    teststat("/bin/zsh/");
    teststat("/bin/zsh/.");
    return 0;
}

% ./a
/bin/zsh stat->0 errno->0
/bin/zsh/ stat->-1 errno->20
/bin/zsh/. stat->-1 errno->20
%

errno 20 is ENOTDIR.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 21:32:01 GMT) Full text and rfc822 format available.

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

From: Mikhail Gusarov <dottedmag <at> dottedmag.net>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>
Subject: Re: bug#30350: Build breakage of master on MacOS 10.13
Date: Tue, 06 Feb 2018 22:31:15 +0100
[Message part 1 (text/plain, inline)]
On Tue, 6 Feb 2018, at 22:29, Philipp Stephani wrote:
>  I'm saying that on OS X stat'ing /bin/zsh and /bin/zsh/ (or
>  /bin/zsh/.) gives different results:>> 
>>  % stat /bin/zsh
>>  16777220 721698 -rwxr-xr-x 1 root wheel 0 610288[1] "Feb  6 22:24:24
>>  2018" "Sep 21 06:35:23 2017" "Nov  6 13:34:29 2017" "Sep 21 06:35:23
>>  2017" 4194304 808 0x80020 /bin/zsh>>  % stat /bin/zsh/.
>>  stat: /bin/zsh/.: stat: Not a directory
>>  % stat /bin/zsh/
>>  stat: /bin/zsh/: stat: Not a directory
>>  %
> 
> That's the behavior required by POSIX, and Linux behaves in
> exactly the same way, so it's not something where we'd need to special-
> case macOS.
Ah, ignore me then, please :)


Links:

  1. tel:06102%2088
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 22:09:02 GMT) Full text and rfc822 format available.

Message #79 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:07:52 +0000
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 22:11:01 GMT) Full text and rfc822 format available.

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 22:46:01 GMT) Full text and rfc822 format available.

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

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 22:54:01 GMT) Full text and rfc822 format available.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>, Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Tue, 6 Feb 2018 17:53:10 -0500
On Tue, Feb 6, 2018 at 5:44 PM, Alan Third <alan <at> 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)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Tue, 06 Feb 2018 23:39:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
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, 6 Feb 2018 15:38:16 -0800
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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sat, 10 Feb 2018 10:48:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sat, 10 Feb 2018 12:47:08 +0200
> Date: Sun, 4 Feb 2018 21:06:15 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: 30350 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 11 Feb 2018 15:57:02 GMT) Full text and rfc822 format available.

Message #97 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: Sun, 11 Feb 2018 15:56:29 +0000
[Message part 1 (text/plain, inline)]
Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 6. Feb. 2018 um
23:10 Uhr:

> 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.
>


...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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 11 Feb 2018 16:02:02 GMT) Full text and rfc822 format available.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 11 Feb 2018 16:01:18 +0000
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> 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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 11 Feb 2018 21:16:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 30350 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 11 Feb 2018 21:15:11 +0000
On Sun, Feb 11, 2018 at 04:01:18PM +0000, Philipp Stephani wrote:
> Alan Third <alan <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Sun, 16 Aug 2020 16:55:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>, Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Sun, 16 Aug 2020 18:53:53 +0200
Alan Third <alan <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30350; Package emacs. (Fri, 02 Oct 2020 04:55:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 30350 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>, Sam Steingold <sds <at> podval.org>
Subject: Re: bug#30350: 27.0.50; Newest master can't run processes on macOS
Date: Fri, 02 Oct 2020 06:54:02 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Alan Third <alan <at> 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




bug closed, send any further explanations to 30350 <at> debbugs.gnu.org and Philipp <p.stephani2 <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 02 Oct 2020 04:55:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 30 Oct 2020 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 150 days ago.

Previous Next


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