Tramp: how to handle make-symbolic-link?

Tramp: how to handle make-symbolic-link?

[Kai Großjohann]

What should be the LINKNAME argument of make-symbolic-link when
invoking Tramp?  For non-absolute link targets, the following appears
natural:

(make-symbolic-link "/user@host:/name/of/file" "linkname")

So the LINKNAME argument does not look like a Tramp filename.  But
what if the target of the symbolic link is an absolute filename?
Which of the two kinds of calls do we expect?

(make-symbolic-link "/user@host:/name/of/file" "/user@host:/path/to/target")
(make-symbolic-link "/user@host:/name/of/file" "/path/to/target")

Thanks,
kai

PS: Surprised that nobody has reported bugs about make-symbolic-link
    in Tramp, yet.  It must have been buggy for years.
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp: how to handle make-symbolic-link?

[Stefan Monnier]

> What should be the LINKNAME argument of make-symbolic-link when
> invoking Tramp?  For non-absolute link targets, the following appears
> natural:
> 
> (make-symbolic-link "/user@host:/name/of/file" "linkname")
> 
> So the LINKNAME argument does not look like a Tramp filename.  But
> what if the target of the symbolic link is an absolute filename?
> Which of the two kinds of calls do we expect?
> 
> (make-symbolic-link "/user@host:/name/of/file" "/user@host:/path/to/target")
> (make-symbolic-link "/user@host:/name/of/file" "/path/to/target")

In my mind, symbolic links are just special kinds of files and their
"target" is just an arbitrary string which happens to be interpreted
by the file-system code (but can also be used for other things, see
for example the .# locking used by Emacs).
So I think Emacs (and thus Tramp) should handle the target as a string,
not as a filename.


	Stefan

Re: Tramp: how to handle make-symbolic-link?

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> So I think Emacs (and thus Tramp) should handle the target as a string,
> not as a filename.

Right.

Maybe there should be a note about this somewhere in the
documentation for make-symbolic-link?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp: how to handle make-symbolic-link?

[Kai Großjohann]

Kai.Grossjohann@cs.uni-dortmund.de (Kai Großjohann) writes:

> What should be the LINKNAME argument of make-symbolic-link when
> invoking Tramp?  For non-absolute link targets, the following appears
> natural:
>
> (make-symbolic-link "/user@host:/name/of/file" "linkname")

It seems I got the order of args wrong.  How confusing.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp: how to handle make-symbolic-link?

[Richard Stallman]

    So the LINKNAME argument does not look like a Tramp filename.  But
    what if the target of the symbolic link is an absolute filename?
    Which of the two kinds of calls do we expect?

    (make-symbolic-link "/user@host:/name/of/file" "/user@host:/path/to/target")
    (make-symbolic-link "/user@host:/name/of/file" "/path/to/target")

I disagree with the view that the link target is just a string.
It is meant to be a file name.

Assuming that symlinks in the remote file system can only point to
that same remote file system, the former request is possible, and the
latter should get an error because there is no way to make a link to
the local machine's disk.

Re: Tramp: how to handle make-symbolic-link?

[Stefan Monnier]

>     So the LINKNAME argument does not look like a Tramp filename.  But
>     what if the target of the symbolic link is an absolute filename?
>     Which of the two kinds of calls do we expect?
> 
>     (make-symbolic-link "/user@host:/name/of/file" "/user@host:/path/to/target")
>     (make-symbolic-link "/user@host:/name/of/file" "/path/to/target")
> 
> I disagree with the view that the link target is just a string.
> It is meant to be a file name.
> 
> Assuming that symlinks in the remote file system can only point to
> that same remote file system, the former request is possible, and the
> latter should get an error because there is no way to make a link to
> the local machine's disk.

make-symbolic-link should not prevent you from creating to a link
to a file that doesn't exist.  Especially since you can pretty much
never tell whether the file will ever exist or not.

Maybe my point of view is too posix-centric, but I really would be
annoyed if eshell prevented me from creating symlinks just on the
basis that Emacs thinks the target is "invalid".  I use invalid
targets all the time (g.e. because the filesystem is currently
mounted at a different location than the "final" one, or because
I want to store non-filenames and have `ls -l' show me that data
or because I know that the data is small and that my filesystem
stores such data more efficiently if I use symlinks rather than
files, ...).
And I don't think my usage pattern is unique.


	Stefan

Re: Tramp: how to handle make-symbolic-link?

[Richard Stallman]

    > Assuming that symlinks in the remote file system can only point to
    > that same remote file system, the former request is possible, and the
    > latter should get an error because there is no way to make a link to
    > the local machine's disk.

    make-symbolic-link should not prevent you from creating to a link
    to a file that doesn't exist.  Especially since you can pretty much
    never tell whether the file will ever exist or not.

I agree, but that is not the issue here.  Either way, it will be
possible to make links to files that don't exist.  The issue is about
links that would appear to point to another machine.  Symbolic links
are interpreted by the OS, and it does not understand Emacs remote
file names.  So a link can only point to a file on the same machine.

In Emacs, that link target is a remote file name.  It always points
to a remote file.

It seems that the consistent scheme is that you specify the link target
using a remote file on the same remote machine, and the mechanism
to create the link deletes the remote prefix before really creating
the link.

That's the consistent thing for absolute link targets.  A relative
link target is another matter.  Since that is relative to the
directory which contains the link, it should not contain a remote
prefix, and you would not try to remove any remote prefix.

Re: Tramp: how to handle make-symbolic-link?

[Stefan Monnier]

>     > Assuming that symlinks in the remote file system can only point to
>     > that same remote file system, the former request is possible, and the
>     > latter should get an error because there is no way to make a link to
>     > the local machine's disk.
> 
>     make-symbolic-link should not prevent you from creating to a link
>     to a file that doesn't exist.  Especially since you can pretty much
>     never tell whether the file will ever exist or not.
> 
> I agree, but that is not the issue here.  Either way, it will be
> possible to make links to files that don't exist.  The issue is about
> links that would appear to point to another machine.  Symbolic links
> are interpreted by the OS, and it does not understand Emacs remote
> file names.  So a link can only point to a file on the same machine.
> 
> In Emacs, that link target is a remote file name.  It always points
> to a remote file.
> 
> It seems that the consistent scheme is that you specify the link target
> using a remote file on the same remote machine, and the mechanism
> to create the link deletes the remote prefix before really creating
> the link.

I was not arguing about the rewrite when the target is
/sameuser@samehost:/destina/tion an error because there is no way to make a link to
the local machine's disk".

I don't like the rewriting, but I can live with it.  OTOH, raising an
error just because Emacs thinks the operation doesn't make any sense
would just be wrong.  Especially since it's not trivial for elisp code
to transform "/destina/tion" into "/sameuser@samehost:/destina/tion".


	Stefan

Re: Tramp: how to handle make-symbolic-link?

[Richard Stallman]

    I don't like the rewriting, but I can live with it.  OTOH, raising an
    error just because Emacs thinks the operation doesn't make any sense
    would just be wrong.  Especially since it's not trivial for elisp code
    to transform "/destina/tion" into "/sameuser@samehost:/destina/tion".

What is your complete proposal?

    Even Emacs uses symlink targets as non-files, for lock files.

Yes it does, and it never tries to open those.
This happens to work, but is not what symlinks are for.
The main purpose of symlinks is to refer to another file.
That is what defines their meaning.

Re: Tramp: how to handle make-symbolic-link?

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I disagree with the view that the link target is just a string.
> It is meant to be a file name.

Maybe we should look at other, analogous cases, where this also
happens.  Here is an example from my personal experience: Solaris
machines can boot via NFS over the network.  So we have a machine
ourserver with a directory /export/root/aclient which is exported via
NFS and used by aclient as root (/) directory.

Now suppose I want to install the machine.  For this, I create the
/export/root/aclient directory and populate it with files.  Suppose
that there needs to be a symlink /some/symlink pointing to
/other/file on that host.

Then, the following sequence of commands (as root@ourserver!) will do
the trick:

    cd /export/root/aclient/some
    ln -s /other/file symlink

Note that I type "/other/file" when issuing a command on ourserver,
where the file is actually known as /export/root/aclient/other/file!

Thus, I think it makes sense to allow the following command:

(make-symbolic-link "/other/file" "/auser@ahost:/some/symlink")

It is exactly analogous to the above-mentioned NFS case.  The symlink
target would be on the machine ahost.

Have I convinced you?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp: how to handle make-symbolic-link?

[Richard Stallman]

    Then, the following sequence of commands (as root@ourserver!) will do
    the trick:

	cd /export/root/aclient/some
	ln -s /other/file symlink

    Note that I type "/other/file" when issuing a command on ourserver,
    where the file is actually known as /export/root/aclient/other/file!

I think that is a bug in NFS.  This symbolic link won't work properly
when used locally.

However, I've changed my mind about the specific question of
how to handle

    (make-symbolic-link "/user@host:/name/of/file" "/path/to/target")

There is only one thing it can possibly mean, which is
to link to a file on /user@host:, so I guess it is ok
to imagine that /user@host: is present.

Re: Tramp: how to handle make-symbolic-link?

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> However, I've changed my mind about the specific question of
> how to handle
>
>     (make-symbolic-link "/user@host:/name/of/file" "/path/to/target")

I think you meant the following?

(make-symbolic-link "/path/to/target" "/user@host:/name/of/file")

> There is only one thing it can possibly mean, which is to link to a
> file on /user@host:, so I guess it is ok to imagine that /user@host:
> is present.

How should the following be handled?

(make-symbolic-link "/user@host:/path/to/target" "/user@host:/path/to/source")
(make-symbolic-link "/user@host:/path/to/target" "/otheruser@otherhost:/path/to/source")
(make-symbolic-link "/user@host:/path/to/target" "/this/is/a/local/source")

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp: how to handle make-symbolic-link?

[Richard Stallman]

    (make-symbolic-link "/user@host:/path/to/target" "/user@host:/path/to/source")

This should work, and make a link that says /path/to/target.

    (make-symbolic-link "/user@host:/path/to/target" "/otheruser@otherhost:/path/to/source")

It would be ok for this to work, exactly like

    (make-symbolic-link "/otheruser@host:/path/to/target" "/otheruser@otherhost:/path/to/source")

However, it would be ok for it to get an error instead.

    (make-symbolic-link "/user@host:/path/to/target" "/this/is/a/local/source")

This should get an error.

Re: Tramp: how to handle make-symbolic-link?

[Stefan Monnier]

>     (make-symbolic-link "/user@host:/path/to/target" "/user@host:/path/to/source")
> 
> This should work, and make a link that says /path/to/target.

This is the part I can agree with.

>     (make-symbolic-link "/user@host:/path/to/target" "/otheruser@otherhost:/path/to/source")
> 
> It would be ok for this to work, exactly like
> 
>     (make-symbolic-link "/otheruser@host:/path/to/target" "/otheruser@otherhost:/path/to/source")
> 
> However, it would be ok for it to get an error instead.
> 
>     (make-symbolic-link "/user@host:/path/to/target" "/this/is/a/local/source")
> 
> This should get an error.

This I *strongly* disagree with.  There is strictly no point in returning
an error in this case and it can be a serious annoyance for some
"unusual" uses.


	Stefan

Re: Tramp: how to handle make-symbolic-link?

[Richard Stallman]

    > However, it would be ok for it to get an error instead.
    > 
    >     (make-symbolic-link "/user@host:/path/to/target" "/this/is/a/local/source")
    > 
    > This should get an error.

    This I *strongly* disagree with.

You can try to convince me.

Re: Tramp: how to handle make-symbolic-link?

[Stefan Monnier]

>     > However, it would be ok for it to get an error instead.
>     > 
>     >     (make-symbolic-link "/user@host:/path/to/target" "/this/is/a/local/source")
>     > 
>     > This should get an error.
> 
>     This I *strongly* disagree with.
> 
> You can try to convince me.

Been there done that,

	
	Stefan

Re: Tramp: how to handle make-symbolic-link?

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     (make-symbolic-link "/user@host:/path/to/target" "/user@host:/path/to/source")
>
> This should work, and make a link that says /path/to/target.
>
>     (make-symbolic-link "/user@host:/path/to/target" "/otheruser@otherhost:/path/to/source")
>
> It would be ok for this to work, exactly like
>
>     (make-symbolic-link "/otheruser@host:/path/to/target" "/otheruser@otherhost:/path/to/source")
>
> However, it would be ok for it to get an error instead.
>
>     (make-symbolic-link "/user@host:/path/to/target" "/this/is/a/local/source")
>
> This should get an error.

Except for the last one (where I don't know the behavior) I've
implemented these.  If the user/host for source and target of the link
are different, I just ignore the user/host component of the target.

Hm.  I guess that there will be some cryptic error message from the
innards of Tramp for the last one...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp: how to handle make-symbolic-link?

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     So the LINKNAME argument does not look like a Tramp filename.  But
|>     what if the target of the symbolic link is an absolute filename?
|>     Which of the two kinds of calls do we expect?
|> 
|>     (make-symbolic-link "/user@host:/name/of/file" "/user@host:/path/to/target")
|>     (make-symbolic-link "/user@host:/name/of/file" "/path/to/target")
|> 
|> I disagree with the view that the link target is just a string.
|> It is meant to be a file name.

Even Emacs uses symlink targets as non-files, for lock files.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."