--- Begin Message ---
|
Subject: |
25.0.50; REGRESSION: `directory-files' raises error for DIR that is `file-accessible-directory-p' |
|
Date: |
Tue, 25 Aug 2015 10:48:10 -0700 (PDT) |
The behavior seems wrong. If so, the regression was introduced in
Emacs 24.5.
emacs -Q
I evaluate these two sexps:
(file-accessible-directory-p
"D:/$RECYCLE.BIN/S-1-5-21-3120201979-235963886-2582836866-1001")
(directory-files
"D:/$RECYCLE.BIN/S-1-5-21-3120201979-235963886-2582836866-1001")
The first returns t. In Emacs prior to Emacs 24.5, the second returns
nil. 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")
* directory-files(
"D:/$RECYCLE.BIN/S-1-5-21-3120201979-235963886-2582836866-1001"
FULL
"^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*")
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)
In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
of 2015-07-31 on LEG570
Bzr revision: 8d332aeccab2208e6c6bd434738565e6abf12043
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#21346: 25.0.50; REGRESSION: `directory-files' raises error for DIR that is `file-accessible-directory-p' |
|
Date: |
Mon, 31 Aug 2015 18:01:36 +0300 |
> Date: Wed, 26 Aug 2015 18:46:58 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
>
> > > > 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.
On further thought, I found a simple and surprisingly efficient method
of testing directory accessibility without any false positives, and
made the corresponding changes.
> > > > 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.
I've now removed that caveat from the doc string.
--- End Message ---