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

[Eli Zaretskii]

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