From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p Date: Sun, 11 May 2014 20:00:48 +0300 Message-ID: <837g5suu67.fsf@gnu.org> References: <83ha51wj35.fsf@gnu.org> <536B1C56.4040307@bluewin.ch> <838uqcw8fu.fsf@gnu.org> <536F5503.4040607@bluewin.ch> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1399827752 11242 80.91.229.3 (11 May 2014 17:02:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 17:02:32 +0000 (UTC) Cc: 17330@debbugs.gnu.org To: Philip Hodges Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 11 19:02:24 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 1WjX8j-0008F7-2Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 19:02:17 +0200 Original-Received: from localhost ([::1]:33686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjX8i-0005AY-Bc for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 13:02:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjX8Z-00059q-Ti for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 13:02:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjX8U-0002N6-M0 for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 13:02:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjX8U-0002Mc-Iy for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 13:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjX8T-00080w-Tp for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 13:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 May 2014 17:02:01 +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.139982767130735 (code B ref 17330); Sun, 11 May 2014 17:02:01 +0000 Original-Received: (at 17330) by debbugs.gnu.org; 11 May 2014 17:01:11 +0000 Original-Received: from localhost ([127.0.0.1]:59469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjX7e-0007zf-SD for submit@debbugs.gnu.org; Sun, 11 May 2014 13:01:11 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:57936) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjX7a-0007yy-Nj for 17330@debbugs.gnu.org; Sun, 11 May 2014 13:01:08 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N5F00P005QK4400@mtaout26.012.net.il> for 17330@debbugs.gnu.org; Sun, 11 May 2014 19:58:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5F00LAC5SU0C40@mtaout26.012.net.il>; Sun, 11 May 2014 19:58:06 +0300 (IDT) In-reply-to: <536F5503.4040607@bluewin.ch> X-012-Sender: halo1@inter.net.il 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:88903 Archived-At: > Date: Sun, 11 May 2014 12:46:27 +0200 > From: Philip Hodges > CC: rgm@gnu.org, 17330@debbugs.gnu.org > > ; 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 Why is that a false negative? According to this: > $ 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) <<<<<<<<<<<<<<<<<<<< you indeed have no "execute/traverse" rights to this directory. It is possible that Cygwin doesn't DTRT with the S-1-5-32-766 well-known SID, which is NT_BUILTIN_CURRENT_OWNER SID. Perhaps it would be a good idea to describe all this on the Cygwin mailing list. > ; in a shell cd to the same 700 folder works fine > $ cd //192.168.0.18/myshare/smb/700 > $ ls > 600 640 644 win So the shell doesn't check, while Emacs does, so what? > $ 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 Irrelevant: native Windows Emacs doesn't examine the ACLs, so it simply has no way of knowing this. > 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? See the relevant functions in files.el. I see no problems here, all of this is expected AFAIU. > 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 As expected, given the ACLs. > insert-directory: Listing directory failed but `access-file' worked > ; which means? It means what it says: you cannot list the directory (i.e. use opendir/readdir APIs), but can successfully call 'access' on it. > 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. The functions are reliable. It's just that you have some obscure situation with the share owner, file/directory owner, and network connection, and this combination bites you. It might also be a Cygwin issue. But I'm tired of wading through all this, so if file-accessible-directory-p does the trick for you, let's forget about the rest.