bug#28156: Emacs quietly munges symlink contents

[Paul Eggert <eggert@cs.ucla.edu>]

On 08/22/2017 12:28 AM, Michael Albinus wrote:
> If you want to have an absolute filename as LINKNAME, you typically call
>
> (make-symbolic-link (expand-file-name target) (expand-file-name linkname))
>
> In case of remote file names, (expand-file-name linkname) will always
> return something like "/method:user@host:/path/to/linkname". I doubt,
> that a user wants to see this literal string as symbolic link.

There seems to be some confusion here, as Bug#28156 does not propose any 
change to how make-symbolic-link's 2nd argument works, (expand-file-name 
linkname) in this case. If the 2nd argument specifies a remote name, as 
in your example, then Tramp will take over and do whatever it wants with 
both arguments, so Bug#28156 is not proposing any change there (although 
perhaps some changes would be helpful for consistency, that's a 
different matter).

Bug#28156 is proposing changes only when the new linkname is local, and 
in those cases, if I'm not mistaken, Emacs currently errors out when the 
target looks like it is remote, so Bug#28156 is merely proposing an 
extension. Emacs routinely creates dangling symlinks with targets 
containing unusual characters like ":", and it wouldn't be surprising if 
users wanted to do something similar on their own.

> Furthermore, there is the OK-IF-ALREADY-EXISTS argument of
> make-symbolic-string. This requires to regard LINKNAME as a file name,
> and not as a literal string.

That's fine, as Bug#28156 is not proposing any change here. LINKNAME 
continues to be treated as a file name under the proposed change. The 
proposed change affects only symlink contents, not symlink names.