bug#21346: 25.0.50; REGRESSION: `directory-files' raises error for DIR that is `file-accessible-directory-p'

[Drew Adams <drew.adams@oracle.com>]

> > 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?  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)
> 
> 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?  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.