bug#17330: files.el cd-absolute overcome false negative from file-executable-p

[Eli Zaretskii]

> Date: Sun, 11 May 2014 12:46:27 +0200
> From: Philip Hodges <philip.hodges@bluewin.ch>
> CC: rgm@gnu.org, 17330@debbugs.gnu.org
> 
> ; cd to the 700 folder does not, this is clearly a false negative:
> cd-absolute: Cannot cd to //192.168.0.18/myshare/smb/700/:  Permission 
> denied

Why is that a false negative?  According to this:

> $ icacls .
> . S-1-5-32-766:(OI)(CI)(RX,W,WDAC,WO,DC)
>    S-1-5-32-767:(OI)(CI)(Rc,S,REA,RA)
>    Everyone:(OI)(CI)(Rc,S,REA,RA)  <<<<<<<<<<<<<<<<<<<<

you indeed have no "execute/traverse" rights to this directory.  It is
possible that Cygwin doesn't DTRT with the S-1-5-32-766 well-known
SID, which is NT_BUILTIN_CURRENT_OWNER SID.  Perhaps it would be a
good idea to describe all this on the Cygwin mailing list.

> ; in a shell cd to the same 700 folder works fine
> $ cd //192.168.0.18/myshare/smb/700
> $ ls
> 600  640  644  win

So the shell doesn't check, while Emacs does, so what?

> $ icacls .
> . S-1-5-32-766:(OI)(CI)(RX,W,WDAC,WO,DC)
>    S-1-5-32-767:(OI)(CI)(Rc,S,REA,RA)
>    Everyone:(OI)(CI)(Rc,S,REA,RA)
> Successfully processed 1 files; Failed processing 0 files
> 
> cygwin emacs-w32 emacs-version "24.3.90.1"
>   (file-executable-p "//192.168.0.18/myshare/smb/700")
> nil
> 
> Native builds do not seem to be affected:
> native emacs-version "24.3.1"
>   (file-executable-p "//192.168.0.18/myshare/smb/700")
> t

Irrelevant: native Windows Emacs doesn't examine the ACLs, so it
simply has no way of knowing this.

> Error reading dir-locals: (file-error "Opening input file" "not a 
> directory" "//mini2012/smb/640/.dir-locals.el")
> ; 640 is a regular file, not a directory, but why dir-locals.el ?
> Error reading dir-locals: (file-error "Opening input file" "permission 
> denied" "//mini2012/smb/700/.dir-locals.el")
> ; 700 is not group read and searchable, but why dir-locals.el ?
> Error: (file-error "Searching for program" "no such file or directory" 
> "bzr")
> ; why does emacs think I want to use bzr with this file?

See the relevant functions in files.el.  I see no problems here, all
of this is expected AFAIU.

> Falling back on "slow" status detection ((file-error "Opening input 
> file" "not a directory" "//mini2012/smb/640/.bzr/checkout/dirstate"))
> File exists, but cannot be read

As expected, given the ACLs.

> insert-directory: Listing directory failed but `access-file' worked
> ; which means?

It means what it says: you cannot list the directory (i.e. use
opendir/readdir APIs), but can successfully call 'access' on it.

> I'm having a hard time understanding why you want to put so much faith 
> in functions that are not reliable now, and will be quite hard or even 
> genuinely impossible to make reliable in all of quite a large number of 
> more or less realistic test scenarios.

The functions are reliable.  It's just that you have some obscure
situation with the share owner, file/directory owner, and network
connection, and this combination bites you.  It might also be a Cygwin
issue.

But I'm tired of wading through all this, so if
file-accessible-directory-p does the trick for you, let's forget about
the rest.