From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philip Hodges Newsgroups: gmane.emacs.bugs Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p Date: Tue, 6 May 2014 00:43:27 +0200 Message-ID: <92953814-A584-41C4-940A-E58514E423AB@bluewin.ch> References: <83r449zf3s.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1399413828 26468 80.91.229.3 (6 May 2014 22:03:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 May 2014 22:03:48 +0000 (UTC) Cc: 17330@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 07 00:03:41 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WhnRG-00038f-At for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 May 2014 00:02:14 +0200 Original-Received: from localhost ([::1]:60090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhRcV-0000Ay-Du for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 May 2014 18:44:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhRcK-0000AN-7O for bug-gnu-emacs@gnu.org; Mon, 05 May 2014 18:44:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhRcB-000514-E5 for bug-gnu-emacs@gnu.org; Mon, 05 May 2014 18:44:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhRcB-00050z-Ai for bug-gnu-emacs@gnu.org; Mon, 05 May 2014 18:44:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WhRcA-0004hh-JN for bug-gnu-emacs@gnu.org; Mon, 05 May 2014 18:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Hodges Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 May 2014 22:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17330 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17330-submit@debbugs.gnu.org id=B17330.139932982218042 (code B ref 17330); Mon, 05 May 2014 22:44:02 +0000 Original-Received: (at 17330) by debbugs.gnu.org; 5 May 2014 22:43:42 +0000 Original-Received: from localhost ([127.0.0.1]:52034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WhRbp-0004gt-9Z for submit@debbugs.gnu.org; Mon, 05 May 2014 18:43:42 -0400 Original-Received: from zhhdzmsp-smta16.bluewin.ch ([195.186.227.132]:56240) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WhRbl-0004gb-E2 for 17330@debbugs.gnu.org; Mon, 05 May 2014 18:43:38 -0400 Original-Received: from [195.186.99.131] ([195.186.99.131:41788] helo=zhbdzmsp-smta13.bluewin.ch) by zhhdzmsp-smta16.bluewin.ch (envelope-from ) (ecelerity 3.5.7.40067 r(Platform:3.5.7.0)) with ESMTP id 3A/EF-13081-01418635; Mon, 05 May 2014 22:43:30 +0000 Original-Received: from [192.168.0.10] (46.127.159.181) by zhbdzmsp-smta13.bluewin.ch (8.5.142) (authenticated as philip.hodges@bluewin.ch) id 51DDDBBD16AD974E; Mon, 5 May 2014 22:43:28 +0000 In-Reply-To: <83r449zf3s.fsf@gnu.org> X-Mailer: Apple Mail (2.1874) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88662 Archived-At: 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? =46rom 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.