From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#28156: Emacs quietly munges symlink contents Date: Tue, 22 Aug 2017 09:03:52 -0700 Organization: UCLA Computer Science Department Message-ID: <787f2dca-7135-3da5-4516-99d12ecf8edd@cs.ucla.edu> References: <68b2e6ef-bf0b-ebcf-c577-d296952d593f@cs.ucla.edu> <83pobqcnlf.fsf@gnu.org> <83h8x2ckqn.fsf@gnu.org> <83bmnacaob.fsf@gnu.org> <1fafa4ea-424e-53c5-3c91-6dd18fe47f1e@cs.ucla.edu> <83bmn8by40.fsf@gnu.org> <5963ac31-06cc-7784-bf21-46b76bd77c51@cs.ucla.edu> <87tw10qcwz.fsf@detlef> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1503419510 3247 195.159.176.226 (22 Aug 2017 16:31:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2017 16:31:50 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Cc: p.stephani2@gmail.com, 28156@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 22 18:31:40 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkC5W-0008Sr-0j for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Aug 2017 18:31:34 +0200 Original-Received: from localhost ([::1]:32819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkC5c-0004Y9-SB for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Aug 2017 12:31:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkBfw-0006H5-60 for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2017 12:05:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkBfq-0000o1-7N for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2017 12:05:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41073) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkBfq-0000nx-4w for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2017 12:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dkBfp-00016b-UN for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2017 12:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2017 16:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28156 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 28156-submit@debbugs.gnu.org id=B28156.15034178424171 (code B ref 28156); Tue, 22 Aug 2017 16:05:01 +0000 Original-Received: (at 28156) by debbugs.gnu.org; 22 Aug 2017 16:04:02 +0000 Original-Received: from localhost ([127.0.0.1]:49754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkBes-000155-06 for submit@debbugs.gnu.org; Tue, 22 Aug 2017 12:04:02 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkBeq-00014i-Hs for 28156@debbugs.gnu.org; Tue, 22 Aug 2017 12:04:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C80F916088A; Tue, 22 Aug 2017 09:03:53 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mTRF2Gtn8BKu; Tue, 22 Aug 2017 09:03:53 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0B539160878; Tue, 22 Aug 2017 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UgNZ7Iu-cnGB; Tue, 22 Aug 2017 09:03:52 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E5393160094; Tue, 22 Aug 2017 09:03:52 -0700 (PDT) In-Reply-To: <87tw10qcwz.fsf@detlef> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136051 Archived-At: 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.