From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21346: 25.0.50; REGRESSION: `directory-files' raises error for DIR that is `file-accessible-directory-p' Date: Tue, 25 Aug 2015 11:34:54 -0700 (PDT) Message-ID: References: <<2974d023-5059-414f-960d-273fbeaca5de@default>> <<83fv37fdcg.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440527726 16323 80.91.229.3 (25 Aug 2015 18:35:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2015 18:35:26 +0000 (UTC) Cc: 21346@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 25 20:35:12 2015 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 1ZUJ3w-0005fr-8T for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 20:35:12 +0200 Original-Received: from localhost ([::1]:34073 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUJ3v-0003ir-Cw for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 14:35:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUJ3n-0003fI-BT for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 14:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUJ3m-0006P8-09 for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 14:35:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUJ3l-0006OX-Tf for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 14:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUJ3l-0001qt-Ma for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 14:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Aug 2015 18:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21346 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21346-submit@debbugs.gnu.org id=B21346.14405277007109 (code B ref 21346); Tue, 25 Aug 2015 18:35:01 +0000 Original-Received: (at 21346) by debbugs.gnu.org; 25 Aug 2015 18:35:00 +0000 Original-Received: from localhost ([127.0.0.1]:38279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUJ3j-0001qZ-Ml for submit@debbugs.gnu.org; Tue, 25 Aug 2015 14:35:00 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:37631) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUJ3h-0001qR-Jm for 21346@debbugs.gnu.org; Tue, 25 Aug 2015 14:34:58 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7PIYt1Y006870 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Aug 2015 18:34:56 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7PIYttK010748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 18:34:55 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7PIYsUt004229; Tue, 25 Aug 2015 18:34:55 GMT In-Reply-To: <<83fv37fdcg.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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: 208.118.235.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:105812 Archived-At: > > In Emacs 24.5 and later I get this error: > > Debugger entered--Lisp error: (file-error "Opening directory" > > "Permission denied" > > "D:/$RECYCLE.BIN/S-1-5-21-3120201979-235963886-2582836866-1001") >=20 > This is the correct behavior in this case: you cannot access that > directory (it is private to another user). Then why does (file-accessible-directory-p "D:/$RECYCLE.BIN/S-1-5-21-3120201979-235963886-2582836866-1001") return t? The doc for that function says that it returns t if I can open the directory. > > Evaluating `file-attributes' for the same file returns this: > > > > (t 1 37786 513 > > (20885 54199 0 0) > > (20885 54199 0 0) > > (20885 54199 0 0) > > 0 "drwxrwxrwx" t 0 506428215) >=20 > What does the following return? >=20 > (file-extended-attributes "D:/$RECYCLE.BIN/S-1-5-21-3120201979- > 235963886-2582836866-1001") ((acl . "O:S-1-5-21-3138815620-4253048750-3916773603-37786G:S-1-5-21-312020= 1979-235963886-2582836866-513D:P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;= ;;S-1-5-21-3120201979-235963886-2582836866-1001)") (selinux-context nil nil nil nil)) What does that tell you? Does it say who the mysterious other user is, to whom the directory is private? > Anyway, Windows has an elaborate file access permissions mechanism > that is not reflected in the Posix-style APIs used by > file-accessible-directory-p and file-attributes. So you have this > inconsistency. That is unfortunate, but since Windows doesn't have > any reliable API that would allow us to perform the accessibility > test, we cannot really improve that situation. I see. What would you suggest, in that case, for filtering out such directories, so the error is not raised? I can wrap the call in `ignore-errors' or equivalent, I suppose. But at that point it might be too late (depending on the context). And given this "inconsistency", don't you think this gotcha should be mentioned in the doc - of `file-accessible-directory-p', for example? That predicate would seem to be unusable as a general test for access to a directory. IOW, what it claims it does is hardly what it does, apparently. And perhaps we need another predicate that actually does what this one says it does, by trying to access the directory? Somewhat akin to `file-remote-p' versus `ffap-file-remote-p'. > IOW, on Windows you can never be sure you can access a file or > directory until you actually try. Fortunately, there are only a few > directories on a typical Windows system where you really cannot > access files. So this problem is rarely seen in practice. Can you characterize those "few directories"? Perhaps they can be described in the doc. Or perhaps `file-accessible-directory-p' can be taught to return nil for them. --- BTW, the doc string of `file-accessible-p' says nothing about what it returns if file FILENAME does NOT name a directory you can open. It should, I think, say what it does (returns nil, raises an error, writes to the the Secretary General of the UN, whatever). Similarly, the manual does not say explicitly that it returns nil if the dir is not accessible, but one can surmise that from the fact that it shows an example where it returns nil and the text says that this implies that attempting to access the directory raises an error. Still, like the doc string, it could be clearer.