From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Tue, 12 Nov 2013 10:19:42 -0500 Message-ID: <21122.18190.51311.720353@consult.pretender> References: <21089.32240.198931.971000@consult.pretender> <87fvrun1pw.fsf@flea.lifelogs.com> <21093.32992.278229.646703@consult.pretender> <877gd5mo5x.fsf@flea.lifelogs.com> <21094.39055.449629.706850@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <21096.24492.292723.589004@consult.pretender> <87eh7bj5no.fsf_-_@flea.lifelogs.com> <21097.10816.221279.461499@consult.pretender> <21097.27136.910137.181740@consult.pretender> <21098.31018.184128.497305@consult.pretender> <87y555socz.fsf@flea.lifelogs.com> <21110.26587.721061.28128@consult.pretender> <83fvrd9ysr.fsf@gnu.org> <877gcorv0r.fsf@flea.lifelogs.com> <83sivc85pe.fsf@gnu.org> <21121.11298.564313.363452@consult.pretender> <83bo1q3dqh.fsf@gnu.org> <21121.20955.967319.163790@consult.pretender> <834n7i2rzd.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1384269677 12882 80.91.229.3 (12 Nov 2013 15:21:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2013 15:21:17 +0000 (UTC) Cc: tzz@lifelogs.com, emacs@kosowsky.org, 15648@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 12 16:21:21 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VgFmI-0005jl-Fw for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 16:21:18 +0100 Original-Received: from localhost ([::1]:43436 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgFmI-0000VM-1B for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 10:21:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgFmA-0000UM-64 for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 10:21:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgFm4-0007Xt-Kn for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 10:21:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgFm4-0007Xm-HV for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 10:21:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VgFm3-0003gL-Ie for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 10:21:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2013 15:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138426961814091 (code B ref 15648); Tue, 12 Nov 2013 15:21:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 12 Nov 2013 15:20:18 +0000 Original-Received: from localhost ([127.0.0.1]:48924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgFlJ-0003fC-5X for submit@debbugs.gnu.org; Tue, 12 Nov 2013 10:20:17 -0500 Original-Received: from vms173001pub.verizon.net ([206.46.173.1]:40067) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgFlF-0003ez-Pm for 15648@debbugs.gnu.org; Tue, 12 Nov 2013 10:20:14 -0500 Original-Received: from consult.pretender ([unknown] [96.237.159.120]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MW500IGOP8VTEB0@vms173001.mailsrvcs.net> for 15648@debbugs.gnu.org; Tue, 12 Nov 2013 09:19:50 -0600 (CST) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id rACFJgE1004196; Tue, 12 Nov 2013 10:19:42 -0500 In-reply-to: <834n7i2rzd.fsf@gnu.org> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80322 Archived-At: Stefan -- please pay attention to the hostile, unfriendly attitude and ultimate arrogance of the Windows Emacs maintainer... Eli Zaretskii wrote at about 05:56:06 +0200 on Tuesday, November 12, 2013: > > From: > > Date: Mon, 11 Nov 2013 16:53:31 -0500 > > Cc: emacs@kosowsky.org, tzz@lifelogs.com, 15648@debbugs.gnu.org > > > > > > The absence of cygwin-mount magic file handling when a file name is > > > > passed directly to the gnutls c-code without going through any of the > > > > standard magic-file-handling file access routines is the crux of the > > > > problem. > > > > > No, the crux of the problem is that you are trying to use a natively > > > built Emacs with file names that make sense only for Cygwin programs. > > > > No, the crux of the problem was and is a bug in the gnutls.el code, > > due to the inconsistency in which magic files are handled. > > 1. file-exists-p is enabled with magic file handling turned on > > Only because you use cygwin-mount. Or any other magic file handler... where file-exists-p changes the file path from something not OS recognizable to something OS recognizable. The same error would occur with ange-ftp and tramp should you use that style filename in gnutls-trustfiles. Unless you want to document gnutls as disallowing magic file handler (and write the code to disable file handlers), then you have a problem. Otherwise, you are knowingly and intentionally writing code that is incompatible with a core emacs feature set. > > > 2. The pass to c-code ignores magic file handling > > Only because you use cygwin-mount. Or any other magic file handler... > > > 3. This causes gnutls.el to crash with a totally incomprehensible > > error message and an equally incomprehensible return code of '-64' > > It no longer crashes. It doesn't crash emacs... but the routine exist on error without human-readable explanation (other than an obscure -64 return value). Is this code? Is this user friendly? > > chooses to ignore magic file handling (in a consistent way), then > > such behavior should ideally be documented in the code. > > Remove cygwin-mount, and that's what will happen. Remove (almost) all file handlers actually... so let's just make magic file handlers illegal or remove them from Emacs.... > > > > If you want Cygwin semantics of file names, use a Cygwin build of > > > Emacs, and this problem will immediately go away. Alternatively, use > > > file names for your certificates that native Windows programs can > > > find, and the problem will also go away immediately. > > > > That is your opinion. Your suggestions that I limit myself to using a > > cygwin-compiled version of emacs are just a workaround for poor > > coding. I'm sorry. > > It's not an issue with code quality. It's simply a consequence of the > fact that Cygwin file names _cannot_ be consistently supported in > native Windows programs. You can solve perhaps 95% or 99% of that, > but not 100%. If you are willing to live with those limitations, > please be free. But it will never be supported all the way, it simply > cannot be. The perfect is the enemy of the good enough. I have offered a patch that substantially improves compatibility without any downside other than your own unsubstantiated biases. > > Others have written cygwin-mount specifically for the use case that I > > have. Since when are the two choices you list, the only ones allowed? > > This whole idea of doing it just your way (or any way) goes against > > the entire emacs philosophy. > > You are entitled to your opinions. But I respectfully disagree, and > as long as I'm hold responsible for the Windows port of Emacs, I'm > sorry, but my opinions weigh slightly more. You are being arrogant. Emacs is about more people than just yourself and about more use cases than just you. Such an attitude is incongruous with an open source project and discourages both users and participants. If such an attitude persists, I will regret helping with debugging this and taking my precious time to test your c-code fix. I had already fixed the problem myself, so with your attitude why would I share my insights with you. I am copying Stefan Monnier here to see if he agrees with your arrogant attitude. > > Magic file handling is a core emacs feature. You have to take such > > functionality into account whether you choose to leverage it or > > not... or else you are contributing to making emacs buggy and > > inconsistent (along with limiting its power) > > Except that Cygwin "magic" cannot be reliably handled that way. The > difference is that for other magic file names, we have a handling > agent that is outside of Emacs. By contrast, cygwin-mount pretends to > do that entirely in Emacs Lisp, which cannot work reliably enough. As > this example shows. It will happen with almost any file handler that uses file-exists-p. > > > 3. Don't mix Cygwin file names with native Windows programs. > > > > #3? Where did you come up with that restriction? Is it documented > > somewhere in the Emacs/Elisp manuals and/or in the release notes? Or > > did you invent that restriction out of thin air? > > It's not an invention. It's the result of many years using Emacs on > Windows and hacking it. You are free to ignore that experience, of > course, but I assure you it is valid. But why would you preclude this from working. Please give me ONE use case where my patch either causes a failure elsewhere or where it bogs down the code. > > > I think you are missing the point that gnutls.el has an inherent > > inconsistency independent of cygwin or anything else... > > It's not just gnutls.el, it's all of Emacs. And for a good reason: > these file names cannot be supported by cygwin-mount or any similar > solutions. You need an external agent that resolves all the Cygwin > file names, any time Emacs needs to access a file, be it in Lisp or in > C. That is your opinion. I have been using cygwin-mount for about a decade without any problems... until now. > > > I have proposed a valid, workable, and very tiny patch. Moreover, my > > patch is totally consistent with the usage of expand-file-name in > > particular and magic file handlers in particular as used dozens of > > times in file.el > > As long as the solution is plugging cygwin-mount into more places in > Emacs, such a solution will not be acceptable, sorry. You are biased against cygwin-mount. A maintainer needs to check his biases at the door. > > > You have failed to give a single use case where my patch would cause > > any problems. My patch adds immeasurably trivial complexity and > > processing time to the routine. In contrast, all you have done is > > suggest one-off workarounds which do nothing to solve the problem for > > the next unsuspecting user... > > I have enough use cases to fill a lecture, I just have no time to > write them all. Sorry, please accept my judgment on this, even if you > disagree. I am just asking for one (reasonable) failure case. I call BS. You are clearly just posturing -- given that you have taken hours to refute everything but the patch itself. If you had a use case at your fingertips, surely you would happily have suggested it long ago...