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

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

bug#17330: closed (files.el cd-absolute overcome false negative from fil


From: GNU bug Tracking System
Subject: bug#17330: closed (files.el cd-absolute overcome false negative from file-executable-p)
Date: Sat, 23 Oct 2021 05:10:02 +0000

Your message dated Fri, 22 Oct 2021 22:09:12 -0700
with message-id 
<CADwFkmnW+uPYviTeDB_9t4gzLV801fLmD78hKMo5RzAkNn2a=w@mail.gmail.com>
and subject line Re: bug#17330: files.el cd-absolute overcome false negative 
from file-executable-p
has caused the debbugs.gnu.org bug report #17330,
regarding files.el cd-absolute overcome false negative from file-executable-p
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
17330: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17330
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: files.el cd-absolute overcome false negative from file-executable-p Date: Wed, 23 Apr 2014 22:54:18 +0200
[using emacs-w32.exe 24.3 in cygwin but also applies to other platforms.]

Symptom:
When I try to cd to my samba-mounted directory,
or try to run ediff-files, it refuses with the error
"Cannot cd to my_directory_name: Permission denied"
The same directory opens fine in dired-mode, and I can open files within it.

A workaround is to make my directory and its parents executable for "others",
but of course it would be much better to keep the correct mode in force.
Maybe a more recent or better configured samba on the server would help.

This is just one way in which file-executable-p can produce a false negative,
where executing the file or searching the directory may succeed after all.

[False positives, where the operation refuses, have no impact so long as
the operation fails quickly with an equivalent but authoritative error message.]

This is typical of many situations where it is not good enough just
to check quickly whether it just looks like it can or cannot be done;
you have to also actually try it, and report the outcome of
that particular attempt at that particular moment.
A preliminary check may still be useful too if it produces a better error
message quickly up front with no dashed expectations or cleaning up to do.

The comments in fileio.c check_executable (and check_writeable) point out
that on some filesystems there might be an access control list (ACL) in force,
and that the effective user might have more permission than the real user.

Suggested fix:
In files.el the function cd-absolute can ask for confirmation in case
check-executable-p might be producing a false negative:

;; in emacs-24.3/lisp/files.el [cd-absolute] replace the expression
    (unless (file-executable-p dir)
      (error "Cannot cd to %s:  Permission denied" dir))
;; with
    (unless (file-executable-p dir)
      (unless (yes-or-no-p
                           (format
                                "Directory does not look searchable; try to cd 
to %s anyway? "
                                dir))
                (error "Cannot cd to %s:  Permission denied" dir)))

I encountered the cd failure originally on invoking ediff-files to merge
source code from a samba mount, then noticed cd itself is affected too.
I haven't run into any other false negative cases.
The 24.3 distribution contains about 50 calls to
file-executable-p where a fix like this might potentially be useful,
not to mention custom code and community packages, and other similar functions.

In directory search contexts file-searchable-p might be a better name.




--- End Message ---
--- Begin Message --- Subject: Re: bug#17330: files.el cd-absolute overcome false negative from file-executable-p Date: Fri, 22 Oct 2021 22:09:12 -0700 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Glenn Morris <rgm@gnu.org> writes:

> I already changed cd-absolute to use file-accessible-directory-p for
> the next release, and documented that f-a-d-p is preferable to
> file-executable-p for such purposes.
>
> If you think anything else need changing, please say so.
> Otherwise perhaps this is done.

This was a sprawling discussion that ranged from not getting a recipe to
not getting a fix tested.  It seems like the conclusion was that this
was fixed, and we've heard nothing more in 7.5 years.  I'm therefore
closing this bug report.

If this conclusion is incorrect and this is still an issue, please reply
to this email (use "Reply to all" in your email client) and we can
reopen the bug report.


--- End Message ---

reply via email to

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