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

Previous Next

Full log

View this message in rfc822 format

From: Philip Hodges <philip.hodges <at> bluewin.ch>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17330 <at> debbugs.gnu.org
Subject: bug#17330: files.el cd-absolute overcome false negative from	file-executable-p
Date: Tue, 6 May 2014 00:43:27 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.