bug#21573: 24.5; file-accessible-directory-p behaves incorrectly with executable file on Mac OS X

bug#21573: 24.5; file-accessible-directory-p behaves incorrectly with executable file on Mac OS X

[Praveen Kumar]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

Create an executable file (script) as follows:


$ cat > /tmp/hello.py

#!/usr/bin/env python

print 'Hello, world!'


$ chmod a+x /tmp/hello.py


Now open the file /tmp/hello.py in Emacs in graphical mode on Mac OS

X. Whil in the hello.py buffer, evaluate the following expression (M-:)


(file-accessible-directory-p buffer-file-name)


This should return nil, because the given file is not a

directory. However, this returns t.


While performing the same in terminal mode, file-accessibel-directory-p

returns nil for the same buffer.


This is inconsistent behavior. This is affecting some extensions those

use this function.




In GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)

of 2015-04-10 on builder10-9.porkrind.org

Windowing system distributor `Apple', version 10.3.1348

Configured using:

`configure --with-ns '--enable-locallisppath=/Library/Application

Support/Emacs/${version}/site-lisp:/Library/Application

Support/Emacs/site-lisp''


Important settings:

  value of $LANG: en_US.UTF-8

  locale-coding-system: utf-8-unix


Major mode: Python


Minor modes in effect:

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


Recent messages:

For information about GNU Emacs and the GNU system, type C-h C-a.

user-error: Beginning of history; no preceding item [2 times]

t

nil

Can't guess python-indent-offset, using defaults: 4

t

Quit

Can't guess python-indent-offset, using defaults: 4

t


Load-path shadows:

None found.


Features:

(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml

mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev

gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util

help-fns mail-prsvr mail-utils vc-git python easymenu json comint ring

cl-loaddefs cl-lib ansi-color time-date tooltip electric uniquify

ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset

image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode

register page menu-bar rfn-eshadow timer select scroll-bar mouse

jit-lock font-lock syntax facemenu font-core frame cham georgian

utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean

japanese hebrew greek romanian slovak czech european ethiopic indian

cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev

minibuffer 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 make-network-process

cocoa ns multi-tty emacs)


Memory information:

((conses 16 80948 5235)

(symbols 48 18314 0)

(miscs 40 48 207)

(strings 32 13377 3859)

(string-bytes 1 387833)

(vectors 16 10470)

(vector-slots 8 385377 7455)

(floats 8 54 283)

(intervals 56 358 4)

(buffers 960 15))

[-- Attachment #2: Type: text/html, Size: 7039 bytes --]

bug#21573: (no subject)

[Alexander Zhukov]

Hi!

Below are the steps I did used to reproduce the problem releated to the
bug.

Please, see https://github.com/magit/magit/issues/2408 for more info.

Here the steps:

1. Create Git repo with a one file: some bash scripts with executable
   bit set, f.e. script.sh.

2. Open fresh terminal. I mean close running terminal app with Cmd-Q and
   run a fresh copy.

3. Run Emacs app like this: /Applications/Emacs.app/Contents/MacOS/Emacs
   -Q &

4. Eval in the scratch buffer (file-accessible-directory-p
   "/private/var/tmp/repo/script.sh"). The result should be 'nil'

5. Open file: C-x C-f ".../script.sh"

6. Go back the scratch buffer and eval
   (file-accessible-directory-p ".../script.sh")
   The result should be 't'.

7. Exit Emacs with C-x C-c

8. Run Emacs from the same terminal window as in 3.

9. Eval in the scratch buffer
   (file-accessible-directory-p "/private/var/tmp/repo/script.sh")
   The result should be t

NB I'm using standard terminal app that goes with OS X.

-- 
Alexander Zhukov

bug#21573: (no subject)

[Eli Zaretskii]

> From: Alexander Zhukov <zuav@crystax.net>
> Date: Wed, 02 Dec 2015 21:11:45 +0300
> 
> 1. Create Git repo with a one file: some bash scripts with executable
>    bit set, f.e. script.sh.
> 
> 2. Open fresh terminal. I mean close running terminal app with Cmd-Q and
>    run a fresh copy.
> 
> 3. Run Emacs app like this: /Applications/Emacs.app/Contents/MacOS/Emacs
>    -Q &
> 
> 4. Eval in the scratch buffer (file-accessible-directory-p
>    "/private/var/tmp/repo/script.sh"). The result should be 'nil'
> 
> 5. Open file: C-x C-f ".../script.sh"
> 
> 6. Go back the scratch buffer and eval
>    (file-accessible-directory-p ".../script.sh")
>    The result should be 't'.

It is nil here.

> 7. Exit Emacs with C-x C-c
> 
> 8. Run Emacs from the same terminal window as in 3.
> 
> 9. Eval in the scratch buffer
>    (file-accessible-directory-p "/private/var/tmp/repo/script.sh")
>    The result should be t

No, it again returns nil here.  As it should, since this file is not a
directory.

> NB I'm using standard terminal app that goes with OS X.

Could be something OS X specific, I tried on GNU/Linux and on Windows,
and the function always returns nil for files that are not
directories.

I tried both in a Git repository where I have many files, and in a
repository where I have only one shell script, as you mentioned.  The
results are always the same.

What version of Emacs do you use?

bug#21573: (no subject)

[Alexander Zhukov]

>>>>> Eli Zaretskii (EZ) writes:

 >> From: Alexander Zhukov <zuav@crystax.net> Date: Wed, 02 Dec 2015
 >> 21:11:45 +0300
 >> 
 >> 1. Create Git repo with a one file: some bash scripts with
 >> executable bit set, f.e. script.sh.
 >> 
 >> 2. Open fresh terminal. I mean close running terminal app with Cmd-Q
 >> and run a fresh copy.
 >> 
 >> 3. Run Emacs app like this:
 >> /Applications/Emacs.app/Contents/MacOS/Emacs -Q &
 >> 
 >> 4. Eval in the scratch buffer (file-accessible-directory-p
 >> "/private/var/tmp/repo/script.sh"). The result should be 'nil'
 >> 
 >> 5. Open file: C-x C-f ".../script.sh"
 >> 
 >> 6. Go back the scratch buffer and eval (file-accessible-directory-p
 >> ".../script.sh") The result should be 't'.

 EZ> It is nil here.

 >> 7. Exit Emacs with C-x C-c
 >> 
 >> 8. Run Emacs from the same terminal window as in 3.
 >> 
 >> 9. Eval in the scratch buffer (file-accessible-directory-p
 >> "/private/var/tmp/repo/script.sh") The result should be t

 EZ> No, it again returns nil here.  As it should, since this file is
 EZ> not a directory.

 >> NB I'm using standard terminal app that goes with OS X.

 EZ> Could be something OS X specific, I tried on GNU/Linux and on
 EZ> Windows, and the function always returns nil for files that are not
 EZ> directories.

 EZ> I tried both in a Git repository where I have many files, and in a
 EZ> repository where I have only one shell script, as you mentioned.
 EZ> The results are always the same.

Yes, it's OS X specific. Even more, it's seems to be specific to my
machine and the author of the original bug. I have reported this bug to
magit initially and so far nobody with OS X machines was able to
reproduce the bug.

 EZ> What version of Emacs do you use?

GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, NS apple-appkit-1347.57) of
2015-04-13 on ithilien

-- 
Alexander Zhukov

bug#21573: (no subject)

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 03 Dec 2015 15:23:41 +0300, Alexander Zhukov <zuav@crystax.net> said:

> Yes, it's OS X specific. Even more, it's seems to be specific to my
> machine and the author of the original bug. I have reported this bug
> to magit initially and so far nobody with OS X machines was able to
> reproduce the bug.

I could reproduce it with the Mac port as well as the NS port on OS X
10.11.  It seems that faccessat (AT_CWD, "pathToExecutable/.", F_OK,
AT_EACCESS) returns 0 after the call to -[NSWindow
setRepresentedFilename:@"pathToExecutable"], which sets the proxy icon
on the title bar.  If you compile the source (faccessattest.m) at the
end of this mail with $ cc faccessattest.m -framework Cocoa, and run
it with $ ./a.out, then the output becomes

-1
0

rather than expected

-1
-1

I've just sent a bug report to Apple.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

#import <Cocoa/Cocoa.h>

int main (int argc, char *argv[])
{
  char *name, *nameWithSlashDot;

  name = argv[argc - 1];
  nameWithSlashDot = alloca (strlen (name) + sizeof ("/."));
  sprintf (nameWithSlashDot, "%s/.", name);

  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  NSWindow *window = [[[NSWindow alloc] init] autorelease];

  printf ("%d\n", faccessat (AT_FDCWD, nameWithSlashDot, F_OK, AT_EACCESS));
  [window setRepresentedFilename:[NSString stringWithUTF8String:name]];
  printf ("%d\n", faccessat (AT_FDCWD, nameWithSlashDot, F_OK, AT_EACCESS));

  [pool release];
}

bug#21573:

[Jonas Bernoulli]

Would it be possible to work around this by replacing

  (file-accessible-directory-p file)

with

  (and (file-directory-p file)
       (file-accessible-directory-p file))

or does `file-directory-p' suffer from the same issue?

bug#21573: 24.5; file-accessible-directory-p behaves incorrectly with executable file on Mac OS X

[Alan Third]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Thu, 03 Dec 2015 15:23:41 +0300, Alexander Zhukov <zuav@crystax.net> said:
>
> I've just sent a bug report to Apple.

I can no longer reproduce this, so presumably Apple have fixed it.
-- 
Alan Third