all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Philip Hodges <philip.hodges@bluewin.ch>
Cc: 17330@debbugs.gnu.org
Subject: bug#17330: files.el cd-absolute overcome false negative from	file-executable-p
Date: Tue, 06 May 2014 10:17:49 +0300	[thread overview]
Message-ID: <83k39zxtnm.fsf@gnu.org> (raw)
In-Reply-To: <92953814-A584-41C4-940A-E58514E423AB@bluewin.ch>

> From: Philip Hodges <philip.hodges@bluewin.ch>
> Date: Tue, 6 May 2014 00:43:27 +0200
> Cc: 17330@debbugs.gnu.org
> 
> After discovering that even C functions can be redefined, today I "activated an advice" so that all file-executable-p C code calls from Lisp return t.
> No unexpected refusals, no noticeable downsides, no waiting months for C code changes to appear in a new official release. The solution is satisfactory in practice. So far as I am concerned, the case can be closed. Can we at least document the unreliability first though?

I don't know what to document, since you never disclosed the details.
Good documentation should not include FUD, it should include details
that are understandable and actionable by users.  Writing such
documentation requires a good understanding of your situation,
something we don't have in this case.

> From the cygwin FAQ: "When working out the Unix-style attribute bits on a file, the library has to fill out some information not provided by the WIN32 API. It *guesses* ..."

That's not directly related to the case in point, AFAIK (and yes, I do
know what Cygwin does to emulate Posix permissions using Windows
ACLs).

> I understand your being curious as to exactly why cygwin cannot guess correctly for this samba mount without going to an awful lot of trouble. But we do already have several statements confirming that it is not usual or practical to even try. These make sense to me. They explain and confirm what I am seeing. The analysis does not need to be complete. It just takes one reproducible false negative in a realistic scenario that is not going to go away anytime soon. At least one of the platform library functions called by file-executable-p sometimes cannot be trusted. That's enough for me. Let's stop trusting it at all.

It is a pity that you don't tell the details.  The result will be that
the problem is perhaps solved for you (using a recipe that many Emacs
users will not know how to reproduce), but not for others.  I urge you
to reconsider.  After all, the amount of words we've wasted here is
surely large enough to describe your issue to the required depth.





  reply	other threads:[~2014-05-06  7:17 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   ` bug#17330: files.el cd-absolute overcome false negative from file-executable-p Philip Hodges
2014-05-04 16:24     ` Eli Zaretskii
2014-05-05 22:43       ` Philip Hodges
2014-05-06  7:17         ` Eli Zaretskii [this message]
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

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

  git send-email \
    --in-reply-to=83k39zxtnm.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=17330@debbugs.gnu.org \
    --cc=philip.hodges@bluewin.ch \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.