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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 25 Aug 2015 11:34:54 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 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.