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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28156 in the body.
You can then email your comments to 28156 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>
Subject: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 03:28:04 -0700

[Message part 1 (text/plain, inline)]

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.

[0001-Do-not-munge-contents-of-local-symbolic-links.patch (text/x-patch, attachment)]

Message #8 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 15:48:30 +0200

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

Hi Paul,

> 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.

I'll have a look on this. Pls give me some days.

Best regards, Michael.

Message #11 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 17:37:00 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 20 Aug 2017 03:28:04 -0700
> Cc: Michael Albinus <michael.albinus <at> gmx.de>
> 
> 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.

Sorry, I'm probably missing something here, but doesn't Emacs behave
here like Unix shell commands do?  For example, I just did

  $ ln -s ~/bin/etags ttt

and the following 'ls' command shows this:

  $ ls -l ttt
  lrwxrwxrwx 1 eliz eliz 22 Aug 20 10:27 ttt -> /home/e/eliz/bin/etags*

AFAIU, this means the shell expanded "~" when it passed it to 'ln'.
And Emacs tries to behave like the shell does in this case (and in
other similar cases).  Why is that wrong?

Moreover, unless I again misunderstand something important, if
make-symbolic-link would create a link like this:

  ttt -> ~/bin/etags

(which is what your proposed change does, right?), then programs which
follow the link will probably fail, because AFAIK most programs don't
expand "~" (with the notable exception of the shell).

What am I missing here?

>  +++
> +** 'file-attributes', 'file-symlink-p' and 'make-symbolic-link' no
> +longer quietly mutate the target of a local symbolic link.  In
> +particular, 'file-attributes' and 'file-symlink-p' no longer prepend
> +"/:" to some targets of local symbolic links, and 'make-symbolic-link'
> +no longer expands '~' at the start of a link target.  This change lets
> +Emacs access and copy arbitrary local symbolic links.

Regardless of the issue at hand, if the change is installed, this text
should be clarified.  As written, I find it very hard to understand
what is the nature of the change, and how does it change the old
behavior.  For example, the reference to "some targets" could benefit
from a couple of examples showing the old and the new behavior in each
case.

Thanks.

Message #14 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 15:09:01 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am So., 20. Aug. 2017 um 16:38 Uhr:

> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Sun, 20 Aug 2017 03:28:04 -0700
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>
> >
> > 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.
>
> Sorry, I'm probably missing something here, but doesn't Emacs behave
> here like Unix shell commands do?  For example, I just did
>
>   $ ln -s ~/bin/etags ttt
>
> and the following 'ls' command shows this:
>
>   $ ls -l ttt
>   lrwxrwxrwx 1 eliz eliz 22 Aug 20 10:27 ttt -> /home/e/eliz/bin/etags*
>
> AFAIU, this means the shell expanded "~" when it passed it to 'ln'.
> And Emacs tries to behave like the shell does in this case (and in
> other similar cases).  Why is that wrong?
>

It makes it impossible to use '~' as a directory name. Higher-level
interactive interfaces such as Shell and Dired can live with such a
restriction, but library APIs need to be able to work with arbitrary inputs.


>
> Moreover, unless I again misunderstand something important, if
> make-symbolic-link would create a link like this:
>
>   ttt -> ~/bin/etags
>
> (which is what your proposed change does, right?), then programs which
> follow the link will probably fail, because AFAIK most programs don't
> expand "~" (with the notable exception of the shell).
>
> What am I missing here?


Callers of `make-symbolic-link' will need to expand the target themselves.

[Message part 2 (text/html, inline)]

Message #17 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: eggert <at> cs.ucla.edu, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 18:38:40 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 20 Aug 2017 15:09:01 +0000
> Cc: michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
> 
> It makes it impossible to use '~' as a directory name. Higher-level interactive interfaces such as Shell and
> Dired can live with such a restriction, but library APIs need to be able to work with arbitrary inputs.

We have quoting for these cases.

> Callers of `make-symbolic-link' will need to expand the target themselves. 

make-symbolic-link is an interactive command, not just a function.

Message #20 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 10:54:45 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:

> We have quoting for these cases.

Quoting does not work for these cases. If I try to rename a symlink to the 
literal string '~eggert' on my machine, Emacs will misbehave as described and 
there is no way to quote the string naming the symlink to fix this.

> doesn't Emacs behave here like Unix shell commands do?

They differ in many ways. Two examples. First, the Unix shell command 'ln -s 
~/$$ def' expands both the "~" and the "$$", whereas (make-symbolic-link "~/$$" 
"def") expands only the "~". Second, the Unix shell command "ln -s def" creates 
a symlink to itself, whereas (make-symbolic-link "def") is an error. Briefly, 
the Unix shell commands are higher-level than the Emacs primitives.

The main points here are (1) Emacs functions should let users create and 
manipulate whatever symlinks they want to, and (2) the documentation has long 
said that symlinks are not expanded.

> If make-symbolic-link would create a link like this:
> 
>   ttt -> ~/bin/etags
> 
> (which is what your proposed change does, right?), then programs which
> follow the link will probably fail

Yes, they will fail unless there is a directory named '~'. That is the intent. 
If I want to create a symlink to my home directory, I can use expand-file-name 
on the link target, before calling make-symbolic-link.

> this text should be clarified.

Sure, that's easy. Revised patch attached.

[0001-Do-not-munge-contents-of-local-symbolic-links.patch (text/x-patch, attachment)]

Message #23 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 20:28:15 +0200

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

>> We have quoting for these cases.
>
> Quoting does not work for these cases. If I try to rename a symlink to
> the literal string '~eggert' on my machine, Emacs will misbehave as
> described and there is no way to quote the string naming the symlink
> to fix this.

(make-symbolic-link "~/.emacs" "/:/tmp/~eggert")

# ls -l /tmp
[...]
lrwxrwxrwx  1 albinus albinus     20 Aug 20 20:24 ~eggert -> /home/albinus/.emacs

(rename-file "/:/tmp/~eggert" "/:/tmp/~albinus")

# ls -l /tmp
[...]
lrwxrwxrwx  1 albinus albinus     20 Aug 20 20:24 ~albinus -> /home/albinus/.emacs

Best regards, Michael.

Message #26 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 11:53:55 -0700

Michael Albinus wrote:
>>> We have quoting for these cases.
>> Quoting does not work for these cases. If I try to rename a symlink to
>> the literal string '~eggert' on my machine, Emacs will misbehave as
>> described and there is no way to quote the string naming the symlink
>> to fix this.
> (make-symbolic-link "~/.emacs" "/:/tmp/~eggert") ...

That's not the problem I was referring to. Sorry, I should have given more 
detail. By "misbehave as described" I was referring to an earlier-mentioned 
scenario where rename-file copies because the source and destination are on 
different filesystems. For example, suppose the current directory is on a 
different filesystem from /tmp, and I execute the following in my *scratch* buffer:

(shell-command "ln -s '~' symlink")
0
(file-symlink-p "symlink")
"~"
(rename-file "symlink" "/tmp/symlink")
nil
(file-symlink-p "/tmp/symlink")
"/home/eggert"

Here, rename-file quietly expands the symlink contents, which is a bug. As far 
as I can see, one cannot work around the bug by using Tramp quoting; for 
example, (rename-file "/:symlink" "/:/tmp/symlink") does the same thing that 
(rename-file "symlink" "/tmp/symlink") does.

Message #29 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 21:15:14 +0200

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

Hi Paul,

> Here, rename-file quietly expands the symlink contents, which is a
> bug. As far as I can see, one cannot work around the bug by using
> Tramp quoting; for example, (rename-file "/:symlink" "/:/tmp/symlink")
> does the same thing that (rename-file "symlink" "/tmp/symlink") does.

Just to understand what you are speaking about: what do you mean with
"Tramp quoting"? A file name starting with "/:" has nothing to do with
Tramp.

(For the rest of your email I need to run some tests)

Best regards, Michael.

Message #32 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 22:16:04 +0300

> Cc: michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 20 Aug 2017 10:54:45 -0700
> 
> > We have quoting for these cases.
> 
> Quoting does not work for these cases. If I try to rename a symlink to the 
> literal string '~eggert' on my machine, Emacs will misbehave as described and 
> there is no way to quote the string naming the symlink to fix this.

That is but one use case of many.  In other cases, quoting does work.

> > doesn't Emacs behave here like Unix shell commands do?
> 
> They differ in many ways. Two examples. First, the Unix shell command 'ln -s 
> ~/$$ def' expands both the "~" and the "$$", whereas (make-symbolic-link "~/$$" 
> "def") expands only the "~". Second, the Unix shell command "ln -s def" creates 
> a symlink to itself, whereas (make-symbolic-link "def") is an error. Briefly, 
> the Unix shell commands are higher-level than the Emacs primitives.

I never said that Emacs does everything the shell does, and does it
exactly like the shell.  I was only talking about "~" expansion, so
let's not muddy the waters by adding more magic characters and
expansions into what is already a tricky issue.

> The main points here are (1) Emacs functions should let users create and 
> manipulate whatever symlinks they want to, and (2) the documentation has long 
> said that symlinks are not expanded.

I agree.  But I think your proposed changes will disallow some of the
users' capabilities to do what you want.  What's more, they seem to
sacrifice a very common interactive use case on behalf of a much more
rare and obscure one.  I'm talking about a user typing this:

  M-x make-symbolic-link RET ~/foo/bar RET /toto/quux RET

AFAIU, with your changes the "~" in the first file name will not be
expanded.  If I'm right, then you will disallow using "~" as the short
for the home directory in this case, which IMO is unacceptable, as
Emacs allows this in any other interactive command that accepts file
names.

At the very least, we should preserve the current ability of the user
to specify "~" shorthands in interactive invocations of
make-symbolic-link.  If you want to allow users to specify a literal
"~" in this scenario, I agree, but it seems like we already allow
that; see Micheal's example.

> > If make-symbolic-link would create a link like this:
> > 
> >   ttt -> ~/bin/etags
> > 
> > (which is what your proposed change does, right?), then programs which
> > follow the link will probably fail
> 
> Yes, they will fail unless there is a directory named '~'. That is the intent. 
> If I want to create a symlink to my home directory, I can use expand-file-name 
> on the link target, before calling make-symbolic-link.

We cannot force users call expand-file-name in interactive use of
these commands.  It's simply unacceptable.  I don't even know how
users could do that in practice -- do you expect them to type TAB or
something?  How can this work?

Message #35 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 22:21:43 +0300

> Cc: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
>  28156 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 20 Aug 2017 11:53:55 -0700
> 
> (shell-command "ln -s '~' symlink")
> 0
> (file-symlink-p "symlink")
> "~"
> (rename-file "symlink" "/tmp/symlink")
> nil
> (file-symlink-p "/tmp/symlink")
> "/home/eggert"

If this is the problem, then let's solve it without affecting
make-symbolic-link.  The problem you show is in file-symlink-p and/or
in rename-file.  Let's solve it there, and let's solve it without
affecting the interactive callers of those functions.

> Here, rename-file quietly expands the symlink contents, which is a bug. As far 
> as I can see, one cannot work around the bug by using Tramp quoting; for 
> example, (rename-file "/:symlink" "/:/tmp/symlink") does the same thing that 
> (rename-file "symlink" "/tmp/symlink") does.

But AFAIU, file-symlink-p can return a quoted name if its argument is
quoted.  Doesn't this allow to solve the problem?

Message #38 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 14:31:40 -0700

Eli Zaretskii wrote:

>> (shell-command "ln -s '~' symlink")
>> 0
>> (file-symlink-p "symlink")
>> "~"
>> (rename-file "symlink" "/tmp/symlink")
>> nil
>> (file-symlink-p "/tmp/symlink")
>> "/home/eggert"
> 
> If this is the problem,

It's just one instance of the problem.

> then let's solve it without affecting
> make-symbolic-link.

This instance of the problem occurs because rename-file calls 
make-symbolic-link, and make-symbolic-link silently alters the link target. The 
real problem here is with make-symbolic-link: the rename-file bug is just a symptom.

>> Here, rename-file quietly expands the symlink contents, which is a bug. As far
>> as I can see, one cannot work around the bug by using Tramp quoting; for
>> example, (rename-file "/:symlink" "/:/tmp/symlink") does the same thing that
>> (rename-file "symlink" "/tmp/symlink") does.
> 
> But AFAIU, file-symlink-p can return a quoted name if its argument is
> quoted.

I don't know what you mean by "quoted". file-symlink-returns a string, and the 
string is supposed to be the contents of the symlink. file-symlink-p is working 
correctly here. It's make-symbolic-link (called from rename-file) that is 
screwing up.

Message #41 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 14:47:02 -0700

Michael Albinus wrote:
> Just to understand what you are speaking about: what do you mean with
> "Tramp quoting"? A file name starting with "/:" has nothing to do with
> Tramp.

Sorry, I'm afraid I don't understand Tramp at all but I don't think it matters. 
By "Tramp quoting" I was referring to the technique you used in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28156#23 to create a symlink whose 
name starts with "~", by prefixing the name with "/:/tmp/". I don't know why the 
"/:" is there and it doesn't really matter, since the bug in question is not 
with the name of the symlink, it is with the contents of the symlink.

Message #44 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, eggert <at> cs.ucla.edu,
 michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 18:19:33 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Callers of `make-symbolic-link' will need to expand the target themselves. 
>
> make-symbolic-link is an interactive command, not just a function.

Can we not just do the expansion in the interactive form then?

Message #47 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: npostavs <at> users.sourceforge.net, Eli Zaretskii <eliz <at> gnu.org>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, michael.albinus <at> gmx.de,
 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 16:00:05 -0700

npostavs <at> users.sourceforge.net wrote:
> Can we not just do the expansion in the interactive form then?

Yes, that makes sense. I'll modify the patch along those lines.

Message #50 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 05:34:14 +0300

> Cc: michael.albinus <at> gmx.de, p.stephani2 <at> gmail.com, 28156 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 20 Aug 2017 14:31:40 -0700
> 
> This instance of the problem occurs because rename-file calls 
> make-symbolic-link, and make-symbolic-link silently alters the link target. The 
> real problem here is with make-symbolic-link: the rename-file bug is just a symptom.

Then you want a way of invoking make-symbolic-link non-interactively
that doesn't expand "~", AFAIU.  No need to affect its interactive
invocation.

> >> Here, rename-file quietly expands the symlink contents, which is a bug. As far
> >> as I can see, one cannot work around the bug by using Tramp quoting; for
> >> example, (rename-file "/:symlink" "/:/tmp/symlink") does the same thing that
> >> (rename-file "symlink" "/tmp/symlink") does.
> > 
> > But AFAIU, file-symlink-p can return a quoted name if its argument is
> > quoted.
> 
> I don't know what you mean by "quoted".

I mean this:

  (file-symlink-p "/:/tmp/symlink")

There's special code in file-symlink-p to support this and return a
quoted name of the symlink target.  For some reason, you wanted to
remove that code.

Message #53 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 09:36:50 +0200

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

Hi Paul,

> By "Tramp quoting" I was referring to the technique you used in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28156#23 to create a
> symlink whose name starts with "~", by prefixing the name with
> "/:/tmp/". I don't know why the "/:" is there ...

See the lower part of (info "(elisp) File Name Expansion")

Best regards, Michael.

Message #56 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 01:34:20 -0700

Eli Zaretskii wrote:

> No need to affect its interactive invocation.

Yes, that's what npostavs suggested too. I plan to look into it.


>    (file-symlink-p "/:/tmp/symlink")
> 
> There's special code in file-symlink-p to support this and return a
> quoted name of the symlink target.  For some reason, you wanted to
> remove that code.

The proposed change to file-symlink-p doesn't affect support for file name 
quoting in its argument string. All it affects is the returned string. There is 
no need for it to quote the returned string, just as there is no need for 
read-file-name to quote the string that it returns. Neither function is 
documented to quote its return value, and neither should do so.

Message #59 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 17:25:37 +0300

> Cc: michael.albinus <at> gmx.de, p.stephani2 <at> gmail.com, 28156 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 21 Aug 2017 01:34:20 -0700
> 
> The proposed change to file-symlink-p doesn't affect support for file name 
> quoting in its argument string. All it affects is the returned string. There is 
> no need for it to quote the returned string

What if readlink returns a name such as "/ssh:foo <at> bar:/quux"?  A
symlink cannot have a remote file name as its target, can it?  So
quoting it sounds like a good way to avoid triggering a slow and
erroneous connection to some possibly non-existent host.  If we don't
quote, the caller might be in for a surprise.

> just as there is no need for read-file-name to quote the string that
> it returns.

read-file-name gets the string from the user, so it's an entirely
different context.  In that context, it's user's responsibility to
quote the file name if needed.

> Neither function is documented to quote its return value, and
> neither should do so.

Documentation in Emacs was never 110% accurate, so reading it as a
kind of formal requirements is not a good idea, IME.  This behavior is
in file-symlink-p since more than 17 years ago, so it's a de-facto
standard by now; if we decide it is what we want, we could document it
and move on.

Message #62 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 08:58:59 -0700

Eli Zaretskii wrote:
> What if readlink returns a name such as "/ssh:foo <at> bar:/quux"?  A
> symlink cannot have a remote file name as its target, can it?

A symlink target is a string, and can have any bytes in it (other than NUL). So 
if FOO is a remote file name then it can have FOO as a target. Of course the OS 
won't interpret the remote file name on its own, just as it won't interpret ~ or 
$ or whatever, but that is OK and expected.

> read-file-name gets the string from the user, so it's an entirely
> different context.

It was just one example, though it remains a good one. Another example is 
(directory-files dir), which does not escape its results even when they begin 
with ~. Really, there is no need or good precedent for the sort of escaping that 
you propose. It is much simpler (and agrees with the documentation and 
intuition) for file-symlink-p to return the results as-is, like directory-files 
does.

Message #65 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 10:34:27 -0700

[Message part 1 (text/plain, inline)]

>> Quoting does not work for these cases. If I try to rename a symlink to the
>> literal string '~eggert' on my machine, Emacs will misbehave as described and
>> there is no way to quote the string naming the symlink to fix this.
> 
> That is but one use case of many.  In other cases, quoting does work.

My point is that there is a bug in some cases. I agree that in other cases, 
make-symbolic-link does work.

> your proposed changes will disallow some of the
> users' capabilities to do what you want.

With the proposed changes a user can create a local symlink to an any string 
supported by the operating system. This change increases users' capabilities, 
compared to what they can do now. This change does not take away any capabilities.

> they seem to
> sacrifice a very common interactive use case on behalf of a much more
> rare and obscure one.  I'm talking about a user typing this:
> 
>    M-x make-symbolic-link RET ~/foo/bar RET /toto/quux RET

Good suggestion, also made by others. Revised patch attached.

[0001-Do-not-munge-contents-of-local-symbolic-links.patch (text/x-patch, attachment)]

Message #68 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 20:59:43 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
> Date: Mon, 21 Aug 2017 10:34:27 -0700
> 
> -  /* If the file name has special constructs in it,
> -     call the corresponding file handler.  */
> -  handler = Ffind_file_name_handler (target, Qmake_symbolic_link);
> -  if (!NILP (handler))
> -    return call4 (handler, Qmake_symbolic_link, target,
> -		  linkname, ok_if_already_exists);
> -

Why remove this part?  You also did not mentioned that in NEWS.

Thanks.

Message #71 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Mon, 21 Aug 2017 13:30:08 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> Why remove this part?  You also did not mentioned that in NEWS.

The symlink target is a string not a file name, so giving it to file name 
handler can cause the make-symbolic-link call to be misinterpreted. Revised NEWS 
in attached patch, with an example.

[0001-Do-not-munge-contents-of-local-symbolic-links.patch (text/x-patch, attachment)]

Message #74 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, p.stephani2 <at> gmail.com, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Tue, 22 Aug 2017 09:28:28 +0200

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

Hi Paul,

> The symlink target is a string not a file name, so giving it to file
> name handler can cause the make-symbolic-link call to be
> misinterpreted.

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.

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.

Best regards, Michael.

Message #77 received at 28156 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #80 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, p.stephani2 <at> gmail.com, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Thu, 24 Aug 2017 13:38:29 +0200

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

> 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).

Sorry, I have confused the 1st and 2nd argument of make-symbolic-link.
Tramp's docstring is wrong, because it does the same error, for decades.
Will fix it.

However, it is Tramp's (almost undocumented) make-symbolic-link
implementation to handle TARGET as well, and to strip the remote part of
this. I wouldn't be surprised if existing packages will be broken if we
change this.

Coming to your examples, I believe the existing implementation gives you
almost all what is needed, with quoting. Using "~" in TARGET:

--8<---------------cut here---------------start------------->8---
M-x make-symbolic-link RET /:~eggert RET /tmp/foo RET

# ls -l /tmp/foo
lrwxrwxrwx 1 albinus albinus 21 Aug 24 13:19 /tmp/foo -> /home/albinus/~eggert
--8<---------------cut here---------------end--------------->8---

It is questionable whether "/:~eggert" shall be expanded to
"/home/albinus/~eggert". I agree with you, that it shouldn't, the target
shall be just  "~eggert".

Using ":" in TARGET would look like:

--8<---------------cut here---------------start------------->8---
M-x make-symbolic-link RET /:/x:y RET /tmp/foo RET

# ls -l /tmp/foo
lrwxrwxrwx 1 albinus albinus 4 Aug 24 13:23 /tmp/foo -> /x:y
--8<---------------cut here---------------end--------------->8---

For a TARGET which looks like a remote file name, I propose to keep the
current behaviour (stripping the remote part). It shall be equivalent to
just using the local file name of TARGET. So we would have:

--8<---------------cut here---------------start------------->8---
M-x make-symbolic-link RET /sudo::/:~eggert RET /sudo::/tmp/bar RET

# ls -l /tmp/bar
lrwxrwxrwx 1 root root 7 Aug 24 13:26 /tmp/bar -> ~eggert

;; This example does not work yet.
M-x make-symbolic-link RET /:~eggert RET /sudo::/tmp/bar RET

# ls -l /tmp/bar
lrwxrwxrwx 1 root root 7 Aug 24 13:26 /tmp/bar -> ~eggert
--8<---------------cut here---------------end--------------->8---



--8<---------------cut here---------------start------------->8---
M-x make-symbolic-link RET /sudo::/:/x:y RET /sudo::/tmp/bar RET

# ls -l /tmp/foo
lrwxrwxrwx 1 root root 4 Aug 24 13:30 /tmp/bar -> /x:y

;; This example does not work yet.
M-x make-symbolic-link RET /:/x:y RET /sudo::/tmp/bar RET

# ls -l /tmp/foo
lrwxrwxrwx 1 root root 4 Aug 24 13:30 /tmp/bar -> /x:y
--8<---------------cut here---------------end--------------->8---

By this, you don't need to handle "~" special in make-symbolic-link, as
your patch proposes. After all, it is just proper file name quoting, and
fixing the bug mentioned above.

Best regards, Michael.

Message #83 received at 28156 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#28156: Emacs quietly munges symlink contents
Date: Thu, 24 Aug 2017 22:12:28 -0700

[Message part 1 (text/plain, inline)]

Michael Albinus wrote:

> it is Tramp's (almost undocumented) make-symbolic-link
> implementation to handle TARGET as well, and to strip the remote part of
> this. I wouldn't be surprised if existing packages will be broken if we
> change this.

That should not be a problem with the proposed patch, as it does not affect how 
Tramp handles TARGET when making a remote symlink.

> --8<---------------cut here---------------start------------->8---
> M-x make-symbolic-link RET /:~eggert RET /tmp/foo RET
> 
> # ls -l /tmp/foo
> lrwxrwxrwx 1 albinus albinus 21 Aug 24 13:19 /tmp/foo -> /home/albinus/~eggert
> --8<---------------cut here---------------end--------------->8---
> 
> It is questionable whether "/:~eggert" shall be expanded to
> "/home/albinus/~eggert". I agree with you, that it shouldn't, the target
> shall be just  "~eggert".

Yes, adding support for /: for interactive use sounds reasonable. I updated the 
patch to do that; please see attached.

> 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.

> it is just proper file name quoting

The target of a local symbolic link is a string. It need not name a file, and 
often does not name a file. Trying to apply some file name rules to it, and not 
others, is confusing and leads to broken code. For backward compatibility we 
appear to need to handle leading ~ in interactive use and to provide an escape 
for leading ~, but let's not try to inflict these complex rules on code. For 
code, make-symbolic-link should just treat a local target as a string, the way 
the OS does.

[0001-Do-not-munge-contents-of-local-symbolic-links.patch (text/x-patch, attachment)]

Message #86 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, p.stephani2 <at> gmail.com, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Fri, 25 Aug 2017 14:45:49 +0200

Paul Eggert <eggert <at> 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.

Message #89 received at 28156 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, p.stephani2 <at> gmail.com, 28156 <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sat, 26 Aug 2017 15:16:13 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Paul,

>> 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.

I've commited a patch to the repo which does it for Tramp. Well, there
are still some minor oddities when testing with the smb method, will fix
this the next days.

>> 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.

Done also.

Best regards, Michael.

Message #94 received at 28156-done <at> debbugs.gnu.org (full text, mbox):

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-done <at> debbugs.gnu.org
Subject: Re: bug#28156: Emacs quietly munges symlink contents
Date: Sat, 26 Aug 2017 18:53:25 -0700

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.

Previous Next

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