* bug#30350: 27.0.50; Newest master can't run processes on macOS
@ 2018-02-04 20:15 Philipp
2018-02-04 20:20 ` Philipp Stephani
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Philipp @ 2018-02-04 20:15 UTC (permalink / raw)
To: 30350
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))
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 20:15 bug#30350: 27.0.50; Newest master can't run processes on macOS Philipp
@ 2018-02-04 20:20 ` Philipp Stephani
2018-02-04 21:06 ` Alan Third
2018-02-04 20:24 ` Eli Zaretskii
2018-02-05 19:13 ` Paul Eggert
2 siblings, 1 reply; 26+ messages in thread
From: Philipp Stephani @ 2018-02-04 20:20 UTC (permalink / raw)
To: 30350
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 20:15 bug#30350: 27.0.50; Newest master can't run processes on macOS Philipp
2018-02-04 20:20 ` Philipp Stephani
@ 2018-02-04 20:24 ` Eli Zaretskii
2018-02-05 19:13 ` Paul Eggert
2 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2018-02-04 20:24 UTC (permalink / raw)
To: Philipp; +Cc: 30350
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 20:20 ` Philipp Stephani
@ 2018-02-04 21:06 ` Alan Third
2018-02-04 21:12 ` Alan Third
2018-02-10 10:47 ` Eli Zaretskii
0 siblings, 2 replies; 26+ messages in thread
From: Alan Third @ 2018-02-04 21:06 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 21:06 ` Alan Third
@ 2018-02-04 21:12 ` Alan Third
2018-02-04 21:28 ` Philipp Stephani
2018-02-10 10:47 ` Eli Zaretskii
1 sibling, 1 reply; 26+ messages in thread
From: Alan Third @ 2018-02-04 21:12 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 21:12 ` Alan Third
@ 2018-02-04 21:28 ` Philipp Stephani
2018-02-04 22:49 ` Alan Third
0 siblings, 1 reply; 26+ messages in thread
From: Philipp Stephani @ 2018-02-04 21:28 UTC (permalink / raw)
To: Alan Third; +Cc: 30350
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 21:28 ` Philipp Stephani
@ 2018-02-04 22:49 ` Alan Third
2018-02-04 23:16 ` Philipp Stephani
0 siblings, 1 reply; 26+ messages in thread
From: Alan Third @ 2018-02-04 22:49 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 22:49 ` Alan Third
@ 2018-02-04 23:16 ` Philipp Stephani
0 siblings, 0 replies; 26+ messages in thread
From: Philipp Stephani @ 2018-02-04 23:16 UTC (permalink / raw)
To: Alan Third; +Cc: 30350
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 20:15 bug#30350: 27.0.50; Newest master can't run processes on macOS Philipp
2018-02-04 20:20 ` Philipp Stephani
2018-02-04 20:24 ` Eli Zaretskii
@ 2018-02-05 19:13 ` Paul Eggert
2018-02-05 19:18 ` Alan Third
2 siblings, 1 reply; 26+ messages in thread
From: Paul Eggert @ 2018-02-05 19:13 UTC (permalink / raw)
To: Philipp; +Cc: 30350, Sam Steingold, Alan Third
[-- 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;
}
^ permalink raw reply related [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-05 19:13 ` Paul Eggert
@ 2018-02-05 19:18 ` Alan Third
2018-02-05 23:56 ` Paul Eggert
0 siblings, 1 reply; 26+ messages in thread
From: Alan Third @ 2018-02-05 19:18 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Philipp, Sam Steingold
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-05 19:18 ` Alan Third
@ 2018-02-05 23:56 ` Paul Eggert
2018-02-06 0:26 ` Philipp Stephani
0 siblings, 1 reply; 26+ messages in thread
From: Paul Eggert @ 2018-02-05 23:56 UTC (permalink / raw)
To: Alan Third; +Cc: 30350, Philipp, Sam Steingold
[-- 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;
}
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-05 23:56 ` Paul Eggert
@ 2018-02-06 0:26 ` Philipp Stephani
2018-02-06 0:36 ` Paul Eggert
2018-02-06 22:07 ` Philipp Stephani
0 siblings, 2 replies; 26+ messages in thread
From: Philipp Stephani @ 2018-02-06 0:26 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Alan Third, Sam Steingold
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 0:26 ` Philipp Stephani
@ 2018-02-06 0:36 ` Paul Eggert
2018-02-06 0:43 ` Philipp Stephani
2018-02-06 8:28 ` Alan Third
2018-02-06 22:07 ` Philipp Stephani
1 sibling, 2 replies; 26+ messages in thread
From: Paul Eggert @ 2018-02-06 0:36 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350, Alan Third, Sam Steingold
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 0:36 ` Paul Eggert
@ 2018-02-06 0:43 ` Philipp Stephani
2018-02-06 23:38 ` Paul Eggert
2018-02-06 8:28 ` Alan Third
1 sibling, 1 reply; 26+ messages in thread
From: Philipp Stephani @ 2018-02-06 0:43 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Alan Third, Sam Steingold
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 0:36 ` Paul Eggert
2018-02-06 0:43 ` Philipp Stephani
@ 2018-02-06 8:28 ` Alan Third
1 sibling, 0 replies; 26+ messages in thread
From: Alan Third @ 2018-02-06 8:28 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Philipp Stephani, Sam Steingold
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 0:26 ` Philipp Stephani
2018-02-06 0:36 ` Paul Eggert
@ 2018-02-06 22:07 ` Philipp Stephani
2018-02-06 22:10 ` Philipp Stephani
2018-02-06 22:44 ` Alan Third
1 sibling, 2 replies; 26+ messages in thread
From: Philipp Stephani @ 2018-02-06 22:07 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Alan Third, Sam Steingold
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 22:07 ` Philipp Stephani
@ 2018-02-06 22:10 ` Philipp Stephani
2018-02-11 15:56 ` Philipp Stephani
2018-02-06 22:44 ` Alan Third
1 sibling, 1 reply; 26+ messages in thread
From: Philipp Stephani @ 2018-02-06 22:10 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Alan Third, Sam Steingold
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 22:07 ` Philipp Stephani
2018-02-06 22:10 ` Philipp Stephani
@ 2018-02-06 22:44 ` Alan Third
2018-02-06 22:53 ` Noam Postavsky
2018-02-11 16:01 ` Philipp Stephani
1 sibling, 2 replies; 26+ messages in thread
From: Alan Third @ 2018-02-06 22:44 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350, Paul Eggert, Sam Steingold
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 22:44 ` Alan Third
@ 2018-02-06 22:53 ` Noam Postavsky
2018-02-11 16:01 ` Philipp Stephani
1 sibling, 0 replies; 26+ messages in thread
From: Noam Postavsky @ 2018-02-06 22:53 UTC (permalink / raw)
To: Alan Third; +Cc: 30350, Philipp Stephani, Paul Eggert, Sam Steingold
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)
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 0:43 ` Philipp Stephani
@ 2018-02-06 23:38 ` Paul Eggert
0 siblings, 0 replies; 26+ messages in thread
From: Paul Eggert @ 2018-02-06 23:38 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350, Alan Third, Sam Steingold
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-04 21:06 ` Alan Third
2018-02-04 21:12 ` Alan Third
@ 2018-02-10 10:47 ` Eli Zaretskii
1 sibling, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2018-02-10 10:47 UTC (permalink / raw)
To: Alan Third; +Cc: 30350, p.stephani2
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 22:10 ` Philipp Stephani
@ 2018-02-11 15:56 ` Philipp Stephani
0 siblings, 0 replies; 26+ messages in thread
From: Philipp Stephani @ 2018-02-11 15:56 UTC (permalink / raw)
To: Paul Eggert; +Cc: 30350, Alan Third, Sam Steingold
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-06 22:44 ` Alan Third
2018-02-06 22:53 ` Noam Postavsky
@ 2018-02-11 16:01 ` Philipp Stephani
2018-02-11 21:15 ` Alan Third
1 sibling, 1 reply; 26+ messages in thread
From: Philipp Stephani @ 2018-02-11 16:01 UTC (permalink / raw)
To: Alan Third; +Cc: 30350, Paul Eggert, Sam Steingold
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-11 16:01 ` Philipp Stephani
@ 2018-02-11 21:15 ` Alan Third
2020-08-16 16:53 ` Lars Ingebrigtsen
0 siblings, 1 reply; 26+ messages in thread
From: Alan Third @ 2018-02-11 21:15 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 30350, Paul Eggert, Sam Steingold
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2018-02-11 21:15 ` Alan Third
@ 2020-08-16 16:53 ` Lars Ingebrigtsen
2020-10-02 4:54 ` Lars Ingebrigtsen
0 siblings, 1 reply; 26+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-16 16:53 UTC (permalink / raw)
To: Alan Third; +Cc: 30350, Philipp Stephani, Paul Eggert, Sam Steingold
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#30350: 27.0.50; Newest master can't run processes on macOS
2020-08-16 16:53 ` Lars Ingebrigtsen
@ 2020-10-02 4:54 ` Lars Ingebrigtsen
0 siblings, 0 replies; 26+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-02 4:54 UTC (permalink / raw)
To: Alan Third; +Cc: 30350, Philipp Stephani, Paul Eggert, Sam Steingold
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
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2020-10-02 4:54 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-04 20:15 bug#30350: 27.0.50; Newest master can't run processes on macOS Philipp
2018-02-04 20:20 ` Philipp Stephani
2018-02-04 21:06 ` Alan Third
2018-02-04 21:12 ` Alan Third
2018-02-04 21:28 ` Philipp Stephani
2018-02-04 22:49 ` Alan Third
2018-02-04 23:16 ` Philipp Stephani
2018-02-10 10:47 ` Eli Zaretskii
2018-02-04 20:24 ` Eli Zaretskii
2018-02-05 19:13 ` Paul Eggert
2018-02-05 19:18 ` Alan Third
2018-02-05 23:56 ` Paul Eggert
2018-02-06 0:26 ` Philipp Stephani
2018-02-06 0:36 ` Paul Eggert
2018-02-06 0:43 ` Philipp Stephani
2018-02-06 23:38 ` Paul Eggert
2018-02-06 8:28 ` Alan Third
2018-02-06 22:07 ` Philipp Stephani
2018-02-06 22:10 ` Philipp Stephani
2018-02-11 15:56 ` Philipp Stephani
2018-02-06 22:44 ` Alan Third
2018-02-06 22:53 ` Noam Postavsky
2018-02-11 16:01 ` Philipp Stephani
2018-02-11 21:15 ` Alan Third
2020-08-16 16:53 ` Lars Ingebrigtsen
2020-10-02 4:54 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).