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

[Eli Zaretskii]

> From: Philip Hodges <philip.hodges@bluewin.ch>
> Date: Tue, 6 May 2014 00:43:27 +0200
> Cc: 17330@debbugs.gnu.org
> 
> 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?

I don't know what to document, since you never disclosed the details.
Good documentation should not include FUD, it should include details
that are understandable and actionable by users.  Writing such
documentation requires a good understanding of your situation,
something we don't have in this case.

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

That's not directly related to the case in point, AFAIK (and yes, I do
know what Cygwin does to emulate Posix permissions using Windows
ACLs).

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

It is a pity that you don't tell the details.  The result will be that
the problem is perhaps solved for you (using a recipe that many Emacs
users will not know how to reproduce), but not for others.  I urge you
to reconsider.  After all, the amount of words we've wasted here is
surely large enough to describe your issue to the required depth.