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

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Sun, 20 Aug 2017 10:29:01 UTC

Severity: normal

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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 <at> debbugs.gnu.org
Subject: bug#28156: Emacs quietly munges symlink contents
Date: Tue, 22 Aug 2017 09:03:52 -0700
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 <at> 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.





This bug report was last modified 7 years and 269 days ago.

Previous Next


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