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

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

bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to


From: emacs
Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely
Date: Mon, 11 Nov 2013 15:00:39 -0500

Ted Zlatanov wrote at about 14:42:46 -0500 on Monday, November 11, 2013:
 > On Mon, 11 Nov 2013 14:12:34 -0500 <address@hidden> wrote: 
 > 
 > > 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.
 > 
 > > So, again I see only 2 solutions:
 > > 1. Change (or omit) the "/usr" path and make it relative to cygwin
 > >    root (though this would not work generally since cygwin root is
 > >    changeable)
 > 
 > > 2. Implement magic handling so that paths are automagically translated
 > >    to be correct at the file system level. In this case, by inserting
 > >    the cygwin root.
 > 
 > Could we just call http://cygwin-lite.sourceforge.net/html/cygpath.html
 > on the path (or the equivalent C function)?  It seems to be guaranteed
 > to work but may be very slow with the execution overhead.
 > 
 > Ted

It would work for cygwin... but I see two limitations:

1. The same problem that affects cygwin-mount, would affect any other
   magic file handler that translates file names, since once again
   file-exists-p would return true, while the path passed to the
   c-code would in general not point to an OS-recognizable file.

   I could even right my own file handler called
   'my-2nd-home' whereby any path beginning with ~~ would be
   translated to /home/my-2nd-home. Then, if I put such a file name in
   gnutls-trustfiles, it would cause gnutls to throw an error when the
   path is passed to the c-code.

   Again, my patch would solve the problem

2. The suggestion seems to be far kluggier than my suggested patch
   since it relies on a user elisp routine passing executing a system
   call to return a path every time a gnutls connection is
   requested. At least cygwin-mount does this only once at startup and
   abstracts the translation away from higher level routines -- which
   is the entire purpose of a magic file handler.

   If cygpath belongs anywhere, it would be in the magic file handling
   code. Though cygwin-mount does this in a "smarter" way by calling
   'mount' once to determine the cygwin prefix once-and-for-all, and
   then whenever a path is passed, the magic handler automatically
   prefixes on the cygwin mount prefix.

Once again, the problem is not cygwin-mount, per-se. The problem is
the inconsistency between using the magic file enabled predicate
file-exists-p to test for a file and then passing that same file name
to c-code that knows nothing about magic file handlers.





reply via email to

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