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: Sun, 11 May 2014 12:46:27 +0200 Message-ID: <536F5503.4040607@bluewin.ch> References: <83ha51wj35.fsf@gnu.org> <536B1C56.4040307@bluewin.ch> <838uqcw8fu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399805253 25048 80.91.229.3 (11 May 2014 10:47:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 10:47:33 +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 Sun May 11 12:47:23 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 1WjRHu-0007TE-Tw for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 12:47:23 +0200 Original-Received: from localhost ([::1]:60561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjRHu-0004vU-Ee for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 06:47:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjRHl-0004vP-4Y for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 06:47:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjRHf-0003zI-2a for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 06:47:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjRHe-0003zE-VG for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 06:47:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjRHc-0004ee-8M for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 06:47:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Hodges Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 May 2014 10:47:04 +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: moreinfo Original-Received: via spool by 17330-submit@debbugs.gnu.org id=B17330.139980520117840 (code B ref 17330); Sun, 11 May 2014 10:47:04 +0000 Original-Received: (at 17330) by debbugs.gnu.org; 11 May 2014 10:46:41 +0000 Original-Received: from localhost ([127.0.0.1]:58802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjRHE-0004df-4P for submit@debbugs.gnu.org; Sun, 11 May 2014 06:46:40 -0400 Original-Received: from zhbdzmsp-smta15.bluewin.ch ([195.186.99.132]:59488) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjRHA-0004dK-Km for 17330@debbugs.gnu.org; Sun, 11 May 2014 06:46:37 -0400 Original-Received: from [195.186.227.131] ([195.186.227.131:63443] helo=zhhdzmsp-smta14.bluewin.ch) by zhbdzmsp-smta15.bluewin.ch (envelope-from ) (ecelerity 3.5.7.40067 r(Platform:3.5.7.0)) with ESMTP id CC/1C-15424-5055F635; Sun, 11 May 2014 10:46:29 +0000 Original-Received: from [192.168.0.13] (46.127.159.181) by zhhdzmsp-smta14.bluewin.ch (8.5.142) (authenticated as philip.hodges) id 52330D9E1088A0E4; Sun, 11 May 2014 10:46:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <838uqcw8fu.fsf@gnu.org> 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:88890 Archived-At: So I started going through my platform collection setting up smb shares, so that I can connect to them, and open from native and cygwin builds. It's harder to provoke a false negative on more recent systems. Usually it's either no connection at all, because I misconfigured something, or the owner and group are interpreted as known, resulting in a rash of positives, a few of which may be false. Eventually I got a false negative result, sharing from Solaris 11.2. The credentials given for the network connection are for the owner of the share, who has full rwx 7 access to all these folders and files. These messages are from cygwin emacs-w32 24.3.90.1: ; ediff-directories on my 700 and 750 folders *does* work: Comparing '//192.168.0.18/myshare/smb/700/600' and '//192.168.0.18/myshare/smb/750/600' modulo 'nil' Comparing files... Done ; 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 ; in a shell cd to the same 700 folder works fine $ cd //192.168.0.18/myshare/smb/700 $ ls 600 640 644 win $ 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 native emacs-version "24.3.90.1" (file-executable-p "//192.168.0.18/myshare/smb/700") t Here are some other unexpected messages encountered on the way in no particular order. Maybe you can eliminate or mitigate some of them. The credentials given for the network connection here are for another user in my group, which causes false positives for 600 and 700 modes, resulting in noisy messages when it fails to work after all. I would so much rather put up with messages like these from a false positive, than be prevented from using the file due to a false negative. Error reading dir-locals: (file-error "Opening input file" "not a directory" "//mini2012/smb/640/.dir-locals.el") ; 640 is a regular file, not a directory, but why dir-locals.el ? Error reading dir-locals: (file-error "Opening input file" "permission denied" "//mini2012/smb/700/.dir-locals.el") ; 700 is not group read and searchable, but why dir-locals.el ? Error: (file-error "Searching for program" "no such file or directory" "bzr") ; why does emacs think I want to use bzr with this file? Falling back on "slow" status detection ((file-error "Opening input file" "not a directory" "//mini2012/smb/640/.bzr/checkout/dirstate")) File exists, but cannot be read insert-directory: Listing directory failed but `access-file' worked ; which means? find-file-noselect-1: Wrong type argument: arrayp, nil 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. ; What is so wrong with: (if (guess-this-will-work-p) (if (try-it-did-it-work-p) "worked as expected, you got lucky" "so many messages, how could it possibly not work") (if (you-want-to-try-it-anyway-be-it-on-your-own-head-p) (if (try-it-did-it-work-p) "so many messages: end of world, or never mind?" "whoo hoo, worked around it, so much for your stupid guess"))) ; instead of (if (guess-this-will-work-p) (if (try-it-did-it-work-p) "worked as expected, you got lucky" "so many messages, how could it possibly not work") "I will not let you even try, even though I sometimes guess wrong"))) On 2014-05-08 18:18, Eli Zaretskii wrote: >> Date: Thu, 08 May 2014 07:55:34 +0200 >> From: Philip Hodges >> CC: rgm@gnu.org, 17330@debbugs.gnu.org >> >>> I prefer to solve the problem rather than ask users work around it. >> >> So when can we reasonably expect a guarantee of no more false negatives >> for users of 24.3 without having to inspect the fileio.c and files.el >> and reinvent an undocumented workaround? > > Emacs 24.3 was released more than a year ago, so fixing this in that > version might be possible only by some suitable change to the > directory's security descriptor outside of Emacs (if such a change is > possible). > > But we can hope to fix this in future versions of Emacs. > >> It will be great if you really can *solve* the problem, even just for >> this one particular scenario. I already suggested a pathological >> counterexample. Other sources mentioned do indicate that it is >> impossible to solve it reliably in general. But perhaps it will be >> enough in practice. > > If we understand the problem in enough detail, we might find a > solution of some sort. > >> Only the positive outcome of file-executable-p is documented as "this >> means you can access files in that directory". The negative outcome is >> not explicitly documented as meaning you cannot, yet that is how callers >> are interpreting it. So there is clearly scope for rewriting the >> documentation and changing the callers' logic to match. > > That is a different, although related discussion. Arguably, if a > directory is not accessible by me, Emacs had better not attempt that, > even if it might succeed, and instead leave it for the user to fix the > access rights by other means. > > But even if we accept your views on this, it is better to try to solve > the problem than work around it. >