GNU bug report logs - #28156
Emacs quietly munges symlink contents

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#28156: closed (Re: bug#28156: Emacs quietly munges symlink
 contents)
Date: Sun, 27 Aug 2017 01:54:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#28156: Emacs quietly munges symlink contents

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 28156 <at> debbugs.gnu.org.

-- 
28156: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28156
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, p.stephani2 <at> gmail.com,
 28156-done <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sat, 26 Aug 2017 18:53:25 -0700

Michael Albinus wrote:

> What about file-truename? I believe it still must quote the result,
> otherwise we run into problems. See
> 
> (make-symbolic-link "/x:y:" "/tmp/foo")
> (file-truename  "/tmp/foo")
> 
> The latter shall return "/:/x:y:" (as of today) instead of
> "/x:y:".

Thanks for catching that. While looking into it, I noticed that file-truename 
has long mishandled symlink contents starting with ~ as in the following example:

$ ln -s '~nosuchuser' /tmp/foo
$ ls -l /tmp/foo
lrwxrwxrwx. 1 eggert eggert 11 Aug 26 18:51 /tmp/foo -> ~nosuchuser
$ src/emacs -Q -batch -eval '(message "%S" (file-truename "/tmp/foo"))'
"/home/eggert/src/gnu/emacs/master-tmp/~nosuchuser"

I fixed both problems.

> Maybe we shall document it as well. Neither the docstring of
> `file-truename', nor the Lisp reference say something about.
Yes, the documentation could stand some improving here. I fixed it up a bit, 
though not in the file-truename area as I'm thinking we may need some more 
changes here and would like to cogitate about it first. I'll CC: you on any 
further bug reports in this area.

I rebased the patch to master which simplified it since I no longer had to worry 
about Tramp tests, and installed the result. Closing this bug report.

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>
Subject: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 03:28:04 -0700

[Message part 4 (text/plain, inline)]

Tags: patch

The attached patch fixes some Emacs behavior that disagrees with the 
documentation.  Although the user manual says that make-symbolic-link "does
not expand the argument TARGET", Emacs expands leading "~" in the target. Also, 
file-symlink-p quietly munges symlink contents if they appear to be a Tramp file 
name. This behavior makes it impossible to write Emacs code that deals with 
arbitrary local symbolic links, and Emacs mishandles copying of some symlinks 
for this reason. At the operating system level, symlink targets are merely 
strings, and are not file names that are interpreted (any interpretation occurs 
later, only when the symlinks are followed), and Emacs should be consistent with 
that.

It strikes me that a similar change probably needs to be made to Tramp, so that 
remote symlinks also can be arbitrary strings too. However, that's outside my 
expertise so this patch affects only local symlink contents.

[0001-Do-not-munge-contents-of-local-symbolic-links.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.