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

[Philip Hodges]

After discovering that even C functions can be redefined, today I "activated an 
advice" so that all file-executable-p C code calls from Lisp return t.
No unexpected refusals, no noticeable downsides, no waiting months for C code 
changes to appear in a new official release. The solution is satisfactory in 
practice. So far as I am concerned, the case can be closed. Can we at least 
document the unreliability first though?

From the cygwin FAQ: "When working out the Unix-style attribute bits on a file, 
the library has to fill out some information not provided by the WIN32 API. It 
*guesses* ..."

I understand your being curious as to exactly why cygwin cannot guess correctly 
for this samba mount without going to an awful lot of trouble. But we do 
already have several statements confirming that it is not usual or practical to 
even try. These make sense to me. They explain and confirm what I am seeing. 
The analysis does not need to be complete. It just takes one reproducible false 
negative in a realistic scenario that is not going to go away anytime soon. At 
least one of the platform library functions called by file-executable-p 
sometimes cannot be trusted. That's enough for me. Let's stop trusting it at 
all.

We could soften all these file permission functions to ask the user if they 
want to try anyway. Then the next person won't have to figure out the checks 
are unreliable and how to override them. I'll try running with that for the 
next few days.