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

[Drew Adams]

> > The doc for that function says that it returns t if I can open the
> > directory.
> 
> On Windows, that test is not reliable enough.

The doc should say that, IMO.

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

The doc of `file-attributes' does not hint (to me) anything about
such a value indicating that the file is private.

> 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.  Where do we see indicated the fact that I do not have
real access to the file?

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

Perhaps what you said above, if nothing more informative can be found:

  On Windows, that test is not reliable enough.

> > 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".  And what you say is not
what the doc claims.  Perhaps the doc should say what you just said,
and mention that that is all it tests, that it is not a general test
for accessibility.

Perhaps the doc should say that the predicate can give a false
positive (t, when the dir is inaccessible).  Can it also give a
false negative (nil when the dir is accessible)?

> > 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.
> 
> > 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.
It would be clear if it said it. ;-)