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

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

[debbugs-tracker] bug#28156: closed (Emacs quietly munges symlink conten


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#28156: closed (Emacs quietly munges symlink contents)
Date: Sun, 27 Aug 2017 01:54:02 +0000

Your message dated Sat, 26 Aug 2017 18:53:25 -0700
with message-id <address@hidden>
and subject line Re: bug#28156: Emacs quietly munges symlink contents
has caused the debbugs.gnu.org bug report #28156,
regarding Emacs quietly munges symlink contents
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
28156: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28156
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Emacs quietly munges symlink contents Date: Sun, 20 Aug 2017 03:28:04 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
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.

Attachment: 0001-Do-not-munge-contents-of-local-symbolic-links.patch
Description: Text Data


--- End Message ---
--- Begin Message --- Subject: Re: bug#28156: Emacs quietly munges symlink contents Date: Sat, 26 Aug 2017 18:53:25 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
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.


--- End Message ---

reply via email to

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