[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28156: Emacs quietly munges symlink contents
From: |
Michael Albinus |
Subject: |
bug#28156: Emacs quietly munges symlink contents |
Date: |
Fri, 25 Aug 2017 14:45:49 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
Paul Eggert <eggert@cs.ucla.edu> writes:
Hi Paul,
>> For a TARGET which looks like a remote file name, I propose to keep the
>> current behaviour (stripping the remote part).
>
> That's fine if LINKNAME is also remote, since symlinks act
> locally. That is, if TARGET and LINKNAME are both remote to the same
> filesystem, Tramp can continue to munge TARGET so that it works on
> that filesystem. However, Tramp should not be in the business of
> specifying symlink behavior for local symbolic links. It should let
> the OS do that. If LINKNAME is local, TARGET should just act as itself
> without Tramp getting in the way.
Tramp checks already in this case, that LINKNAME and TARGET belong to
the same remote filesystem. I just need to add the case, that TARGET is
used literally otherwise.
> diff --git a/etc/NEWS b/etc/NEWS
> index bf59749..60ddf54 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -1228,6 +1228,30 @@ instead of to utf-8. Before this change, Emacs would
> sometimes
> mishandle file names containing these control characters.
>
> +++
> +** 'file-attributes', 'file-symlink-p' and 'make-symbolic-link' no
> +longer quietly mutate the target of a local symbolic link, so that
> +Emacs can access and copy them reliably regardless of their contents.
> +The following changes are involved.
> +
> +*** 'file-attributes' and 'file-symlink-p' no longer prepend "/:" to
> +symbolic links whose targets begin with "/" and contain ":". For
> +example, if a symbolic link "x" has a target "/y:z", (file-symlink-p
> +"x") now returns "/y:z" rather than "/:/y:z".
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:". Otherwise, we would allow symbolic links over filesystem
borders inside Emacs, which would be a security problem.
Maybe we shall document it as well. Neither the docstring of
`file-truename', nor the Lisp reference say something about.
> diff --git a/test/lisp/net/tramp-tests.el b/test/lisp/net/tramp-tests.el
> index 55f4b52..99a21f3 100644
> --- a/test/lisp/net/tramp-tests.el
> +++ b/test/lisp/net/tramp-tests.el
You don't need to do this, I'll care for Tramp. Likely, I will add
further tests here.
Best regards, Michael.
- bug#28156: Emacs quietly munges symlink contents, (continued)
- bug#28156: Emacs quietly munges symlink contents, Eli Zaretskii, 2017/08/20
- bug#28156: Emacs quietly munges symlink contents, Paul Eggert, 2017/08/21
- bug#28156: Emacs quietly munges symlink contents, Eli Zaretskii, 2017/08/21
- bug#28156: Emacs quietly munges symlink contents, Paul Eggert, 2017/08/21
- bug#28156: Emacs quietly munges symlink contents, Michael Albinus, 2017/08/22
- bug#28156: Emacs quietly munges symlink contents, Paul Eggert, 2017/08/22
- bug#28156: Emacs quietly munges symlink contents, Michael Albinus, 2017/08/24
- bug#28156: Emacs quietly munges symlink contents, Paul Eggert, 2017/08/25
- bug#28156: Emacs quietly munges symlink contents,
Michael Albinus <=
- bug#28156: Emacs quietly munges symlink contents, Michael Albinus, 2017/08/26
- bug#28156: Emacs quietly munges symlink contents, Paul Eggert, 2017/08/26
- bug#28156: Emacs quietly munges symlink contents, npostavs, 2017/08/20
- bug#28156: Emacs quietly munges symlink contents, Paul Eggert, 2017/08/20