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#21346: 25.0.50; REGRESSION: `directory-files' raises error for DIR that is `file-accessible-directory-p' Date: Tue, 25 Aug 2015 22:09:09 +0300 Message-ID: <83egirfane.fsf@gnu.org> References: <2974d023-5059-414f-960d-273fbeaca5de@default> <83fv37fdcg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1440529825 17410 80.91.229.3 (25 Aug 2015 19:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2015 19:10:25 +0000 (UTC) Cc: 21346@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 25 21:10:14 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 1ZUJbq-0002Er-4u for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 21:10:14 +0200 Original-Received: from localhost ([::1]:34164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUJbp-0002Ma-Bs for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 15:10:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUJbl-0002L6-Sa for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 15:10:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUJbf-0007qR-VB for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 15:10:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46075) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUJbf-0007pk-SJ for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 15:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUJbf-0002e8-0f for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 15:10:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Aug 2015 19:10:02 +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.144052976510117 (code B ref 21346); Tue, 25 Aug 2015 19:10:02 +0000 Original-Received: (at 21346) by debbugs.gnu.org; 25 Aug 2015 19:09:25 +0000 Original-Received: from localhost ([127.0.0.1]:38285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUJb3-0002d6-3r for submit@debbugs.gnu.org; Tue, 25 Aug 2015 15:09:25 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:47910) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUJaz-0002cx-SL for 21346@debbugs.gnu.org; Tue, 25 Aug 2015 15:09:23 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NTN00600J4I7L00@mtaout24.012.net.il> for 21346@debbugs.gnu.org; Tue, 25 Aug 2015 22:01:23 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTN002X1JIB7E40@mtaout24.012.net.il>; Tue, 25 Aug 2015 22:01:23 +0300 (IDT) In-reply-to: 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: 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:105813 Archived-At: > Date: Tue, 25 Aug 2015 11:34:54 -0700 (PDT) > From: Drew Adams > Cc: 21346@debbugs.gnu.org > > > > 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") > > > > 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? I explained that later in my response. > The doc for that function says that it returns t if I can open the > directory. On Windows, that test is not reliable enough. > > What does the following return? > > > > (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-3120201979-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? That the file is indeed a private one. > Does it say who the mysterious other user is, to whom the directory > is private? That's not what I wanted to see there. If you want to know who is its owner, try this: (file-attributes "D:/$RECYCLE.BIN/S-1-5-21-3120201979-235963886-2582836866-1001" 'string) The name of the owner will show up as the 3rd element of the list it returns, and the name of the group (I'm guessing "None") as the 4th element. (Unless file-attributes also signals an error.) > > 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). Catching and ignoring errors is the only way, I think. > And given this "inconsistency", don't you think this gotcha should be > mentioned in the doc - of `file-accessible-directory-p', for example? Maybe. I'll have to think of a useful way of describing this. > 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. It's not unusable. It checks the read-only bit (and the executable bit for files). > And perhaps we need another predicate that actually does what this > one says it does, by trying to access the directory? It would be too expensive to be useful, I think. Just trying to read it, like you did, is good enough. > > 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"? Mostly, those under C:/Users/, and also in the recycle bin. Also, a small number of system directories on C:. > 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. Anything but t means it's not accessible. I think this much is clear from the doc string.