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: Wed, 26 Aug 2015 18:46:58 +0300 Message-ID: <83lhcy59xp.fsf@gnu.org> References: <2974d023-5059-414f-960d-273fbeaca5de@default> <83fv37fdcg.fsf@gnu.org> <83egirfane.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1440604112 7600 80.91.229.3 (26 Aug 2015 15:48:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2015 15:48:32 +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 Wed Aug 26 17:48:13 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 1ZUcvr-0002u9-Mv for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 17:48:11 +0200 Original-Received: from localhost ([::1]:38964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUcvq-0005BF-TZ for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 11:48:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUcvm-0005Ay-Vw for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 11:48:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUcvh-0006ex-Ts for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 11:48:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUcvh-0006et-QZ for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 11:48:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUcvh-0007cM-NF for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 11:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Aug 2015 15:48: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.144060402429213 (code B ref 21346); Wed, 26 Aug 2015 15:48:01 +0000 Original-Received: (at 21346) by debbugs.gnu.org; 26 Aug 2015 15:47:04 +0000 Original-Received: from localhost ([127.0.0.1]:38954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUcul-0007b2-UP for submit@debbugs.gnu.org; Wed, 26 Aug 2015 11:47:04 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:33877) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUcuj-0007aX-1D for 21346@debbugs.gnu.org; Wed, 26 Aug 2015 11:47:02 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NTP00D0053O0800@mtaout29.012.net.il> for 21346@debbugs.gnu.org; Wed, 26 Aug 2015 18:47:09 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTP00BEV56L0B20@mtaout29.012.net.il>; Wed, 26 Aug 2015 18:47:09 +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:105839 Archived-At: > Date: Tue, 25 Aug 2015 13:55:13 -0700 (PDT) > From: Drew Adams > Cc: 21346@debbugs.gnu.org > > > 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-..." 'string) > > (t 1 "ME" "Domain Users" > (20885 54199 0 0) > (20885 54199 0 0) > (20885 54199 0 0) > 0 "drwxrwxrwx" t 0 506428215) > > Where ME is my user name. ME is also the value of `user-real-login-name'. > In what way does this return value indicate that I do not (user ME does > not) have access to the file? It doesn't. Which is why I asked for the output of file-extended-attributes. > The doc of `file-attributes' does not hint (to me) anything about > such a value indicating that the file is private. If the mode bits were "drwx------", then it'd be private. But this cannot happen on Windows, due to the way Emacs emulates the Posix mode bits. > > 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.) > > So I am apparently the owner, and the group is Domain Users, to which > I belong. You are the owner, but you are not given access to that directory, yes. > Where do we see indicated the fact that I do not have real access to > the file? In the output of file-extended-attributes. But that is hard to interpret by mere mortals, so type this command from the Windows shell prompt to see a human-readable description: icacls d:\$RECYCLE.BIN\S-1-5-21-3120201979-235963886-2582836866-1001 It's quite possible that the command will say "Access denied". If it does, you need to run that command from a cmd shell session started "as administrator" (e.g., by right-clicking on "command prompt" desktop shortcut or on its shortcut in the Start dialog, selecting "Run as administrator", and clicking YES on the privilege elevation dialog). Btw, if you run Emacs from cmd that was started "as administrator", the call to directory-files for that directory will most probably succeed, and show you the files in that user's recycle bin. > > > 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. > > Perhaps what you said above, if nothing more informative can be found: > > On Windows, that test is not reliable enough. Done. > > > 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). > > Unusable "as a general test for access". I disagree. It does test that the file exists and is a directory, so it _will_ tell you when either of these 2 conditions is false. It just can yield a false positive regarding the success of opening and reading the directory. The alternative is to complicate the heck out of the implementation, make it much slower, and get false negatives instead. I think the alternative is worse. > Can it also give a false negative (nil when the dir is accessible)? Not on Windows, AFAIK. > > > 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. > > That is clear to you, but it is not clear from the doc string, IMHO. The doc string says "Return t if file FILENAME names a directory you can open.". Ergo, if it returns something else, FILENAME is either NOT a directory or you can NOT open it. I fail to see how this could be unclear, it's elementary logic for predicates.