unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Hodges <philip.hodges@bluewin.ch>
To: 17330@debbugs.gnu.org
Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p
Date: Sun, 4 May 2014 15:24:35 +0200	[thread overview]
Message-ID: <E3E812CF-BBF0-4457-85FF-719E81B25D0B@bluewin.ch> (raw)
In-Reply-To: <B19852EC-705B-4D6B-BA06-A175AF2F9B5A@bluewin.ch>

I came across a post that confirms my suspicions that:
- the _stat st_mode bits really cannot be trusted to give a meaningful answer, no matter whether it comes from Windows or cygwin.
- it is not worth calling GetFileSecurity (which is what I meant by "something like GetFileAttributes" *) and trying to reproduce the interpretation of the ACL information
- the best way is to find out if searching a directory will succeed really is to actually try it

http://stackoverflow.com/questions/3449465/find-the-permissions-of-a-file-in-windows

> ... somewhere between hard and impossible to reproduce ...
To reproduce on any platform, simply change check_executable to *always* return false. The easiest way to test what happens with false negatives is to have negatives all the time.

The more I read about it and think about it, the more I stand by my original change suggestion: tell the user that the directory might not be searchable, ask them if they want to go ahead and try it anyway. And also ask if they always want to do that, in case the question appears so often that it becomes annoying. I think we have to accept and work with what we have got instead of punishing users until such time as every possible combination of filesystem and library methods can be upgraded in a way that might not even be practical for many of them.

Surely the worst that can happen is that it becomes easier to end up with a buffer whose current directory really is not searchable, or file changes that cannot be saved in the original location. Good to avoid, but not vital. Rather that than being completely denied the use of a feature such as ediff-directories that would actually work.

Much of what was written for #10257 (writeable) applies to this #17330 (searchable directory) and vice versa. So if we are only comfortable with just treating a -1 uid or gid specially here too, well it is not a general solution, but better than no change at all. Having just the default entries in the passwd file hasn't been causing me any other noticeable trouble.

[*) If I have mixed up any other detail such as which conditional compiling macros are defined to choose between euidaccess and stat or _stat in which builds, or misreported something observed on a system that is not in front of me at that moment, please forgive me.]




  reply	other threads:[~2014-05-04 13:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 20:54 bug#17330: files.el cd-absolute overcome false negative from file-executable-p Philip Hodges
2014-05-03  0:24 ` Glenn Morris
2014-05-03  9:17   ` Philip Hodges
2014-05-03  9:35     ` Achim Gratz
2014-05-03 13:26       ` Eli Zaretskii
2014-05-03 13:58         ` Achim Gratz
2014-05-03 16:37           ` Eli Zaretskii
2014-05-03 13:40     ` Eli Zaretskii
2014-05-04  4:16     ` Glenn Morris
2014-05-04 13:01       ` Stefan Monnier
2014-05-04 16:18         ` Eli Zaretskii
2014-05-04 18:07         ` Glenn Morris
2014-05-04 22:44           ` Stefan Monnier
2014-05-09  6:54             ` Glenn Morris
2014-05-03 22:43 ` bug#17330: thanks for the comments Philip Hodges
2014-05-04 13:24   ` Philip Hodges [this message]
2014-05-04 16:24     ` bug#17330: files.el cd-absolute overcome false negative from file-executable-p Eli Zaretskii
2014-05-05 22:43       ` Philip Hodges
2014-05-06  7:17         ` Eli Zaretskii
2014-05-06 12:46         ` Stefan Monnier
2014-05-06 16:56           ` Glenn Morris
2014-05-11 13:55             ` Philip Hodges
2014-05-06  4:15 ` Glenn Morris
     [not found] <E6923B15-B9A8-4B3C-ADDF-713810613ADD@bluewin.ch>
2014-05-07 18:15 ` Eli Zaretskii
2014-05-08  5:55   ` Philip Hodges
2014-05-08  7:09     ` Glenn Morris
2014-05-08 16:18     ` Eli Zaretskii
2014-05-11 10:46       ` Philip Hodges
2014-05-11 17:00         ` Eli Zaretskii
2014-05-11 18:26           ` Philip Hodges
2014-05-11 18:38             ` Glenn Morris
2014-05-11 21:59               ` Philip Hodges
2014-05-12  7:10                 ` Glenn Morris
2014-05-12  7:26                   ` Philip Hodges
2021-10-23  5:09               ` Stefan Kangas
2014-05-11 18:43             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E3E812CF-BBF0-4457-85FF-719E81B25D0B@bluewin.ch \
    --to=philip.hodges@bluewin.ch \
    --cc=17330@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).