bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21346: 25.0.50; REGRESSION: `directory-files' raises error for DIR t


From: Eli Zaretskii
Subject: bug#21346: 25.0.50; REGRESSION: `directory-files' raises error for DIR that is `file-accessible-directory-p'
Date: Tue, 25 Aug 2015 21:10:55 +0300

> Date: Tue, 25 Aug 2015 10:48:10 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> The behavior seems wrong.  If so, the regression was introduced in
> Emacs 24.5.

No, Emacs 24.5 fixed a bug that existed in previous versions.

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

The latter result was a clear bug.

> 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
>  "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*")

This is the correct behavior in this case: you cannot access that
directory (it is private to another user).  Emacs 24.4 and before
would silently return nil there, which is obviously bogus (there's no
directory, except the root, without at least 2 entries, so what the
heck does nil mean here?).

I'm guessing that you cannot display that directory's contents from
the Windows Explorer as well.

> 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")

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.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]