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

[Philip Hodges]

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

It's a false negative because the folder belongs to the host user I 
connected as, and that user happens to be able to do anything with it, 
including cd, if only cd-absolute would actually try it. I'm not just 
"everyone", I also happen to be the owner. Of course in the general case 
there might be host groups involved too, or even host ACLs.

> > ; 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?

Because cd and ls in that directory work in a cygwin shell, but opening 
and changing to that same directory do not work in cygwin emacs-w32.

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

However it got there, whether by guesswork or sheer optimism, it 
happened to come up with the right answer.

>> ...

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

They are subject to race conditions, false positives and false 
negatives. They are reliable only in the sense that they generally do 
return (unless the network hangs, is there any way to stay responsive 
when that happens?) and the answer is quite often a true positive or 
true negative.

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

I just skimmed through yet another tiring article about how there are 
fundamental reasons why cygwin can't always get permissions and ACLs 
exactly right, even without specifically mentioning remote SMB servers. 
I'm quite convinced the cygwin folks would have already done it if it 
was actually possible.

But I'm also curious about why different SMB implementations make a 
difference. If it was affecting Samba (recent with SMB2?) on GNU/Linux 
or Apple's own new SMB in MacOSX 10.9 (which defaults to SMB2.x) instead 
of just Oracle's Solaris (likely still SMB1) then would you still write 
it off as obscure? I didn't try a GNU/Linux yet by the way, it took me 
long enough just to find out how to configure a smb share on Solaris 
(with zfs commands on 11.2) and have virtualbox make it visible on my 
network (bridge).

I do appreciate your patience and tenacity. This thread just grew and 
grew longer against my expectations. I wish now that I had done more 
research and testing up front. And taken more care to note down or 
remember the getfacl command correctly, instead of recalling it as the 
typo fgetacl.