file-symlink-p for remote files?

file-symlink-p for remote files?

[Kai Großjohann]

Let's say I have a remote system with a symlink, like so:

$ ls -ld /foo
lrwxrwxrwx    1 root     root            9 Feb 28 14:51 /foo -> /bar

Note that the symlink target is given as an absolute name.

Which value should be returned by (file-symlink-p "/user@host:/foo")?

( ) "/user@host:/bar"
( ) "/bar"
( ) something else, please specify: ___________________________
-- 
A preposition is not a good thing to end a sentence with.

Re: file-symlink-p for remote files?

[Stefan Monnier]

> Let's say I have a remote system with a symlink, like so:
> 
> $ ls -ld /foo
> lrwxrwxrwx    1 root     root            9 Feb 28 14:51 /foo -> /bar
> 
> Note that the symlink target is given as an absolute name.
> 
> Which value should be returned by (file-symlink-p "/user@host:/foo")?
> 
> (1) "/user@host:/bar"
> (2) "/bar"
> (3) something else, please specify: ___________________________

I like to think of symlinks as "special files" that can contain arbitrary
text (as used for example by Emacs in its file locking protocol),
but in practice this poses problems, so I think the right answer is
option (1).  See for example ange-ftp.
The reason is that there are elisp routines (such as file-truename
I guess) that do the symlink-dereference manually rather than relying
on the OS to do it for use.


	Stefan

Re: file-symlink-p for remote files?

[Kai Großjohann]

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

> I like to think of symlinks as "special files" that can contain arbitrary
> text (as used for example by Emacs in its file locking protocol),
> but in practice this poses problems, so I think the right answer is
> option (1).  See for example ange-ftp.

I just checked in a change that changes Ange-FTP from (1) to (2).
Now we have to find another way to solve the original problem :-)
-- 
A preposition is not a good thing to end a sentence with.

Re: file-symlink-p for remote files?

[Stefan Monnier]

> > I like to think of symlinks as "special files" that can contain arbitrary
> > text (as used for example by Emacs in its file locking protocol),
> > but in practice this poses problems, so I think the right answer is
> > option (1).  See for example ange-ftp.
> 
> I just checked in a change that changes Ange-FTP from (1) to (2).

What for, exactly ?


	Stefan

Re: file-symlink-p for remote files?

[Kai Großjohann]

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

>> > I like to think of symlinks as "special files" that can contain arbitrary
>> > text (as used for example by Emacs in its file locking protocol),
>> > but in practice this poses problems, so I think the right answer is
>> > option (1).  See for example ange-ftp.
>> 
>> I just checked in a change that changes Ange-FTP from (1) to (2).
>
> What for, exactly ?

Bugfix.  There was a problem with tramp and dired and symlinks.  I
forget what exactly was the problem.

But it will be changed back.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-symlink-p for remote files?

[Stefan Monnier]

> >> I just checked in a change that changes Ange-FTP from (1) to (2).
> > What for, exactly ?
> Bugfix.  There was a problem with tramp and dired and symlinks.  I
> forget what exactly was the problem.

Then maybe we should use another bug-fix.
Of course, that would first require to be able to figure out
what was this problem.


	Stefan

Re: file-symlink-p for remote files?

[Richard Stallman]

file-symlink-p should return the exact link target.  (When the target
is relative, file-symlink-p returns the relative name.)
I corrected the doc string.

Because it is useful to be able to find the file name that the link
points to, I just gave file-chase-links an optional argument to
specify the maximum number of links to chase.

Meanwhile, I think it is necessary to modify file-chase-links and
file-truename to do something special for remote symbolic links.
Could you do that?

Re: file-symlink-p for remote files?

[Richard Stallman]

    I just checked in a change that changes Ange-FTP from (1) to (2).

That is good.  Please don't undo that change.

Re: file-symlink-p for remote files?

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> file-symlink-p should return the exact link target.  (When the target
> is relative, file-symlink-p returns the relative name.)

I confess that I'm rather surprised by this decision.  It appears to
be inconsistent with another decision on make-symbolic-link that you
took some months ago.

It seems to me that the target of a symlink should either be
interpreted as a string by both functions, or it should be
interpreted as a filename by both functions.

So much for my opinion.  Some observations:

Previously, you decided that the target of the symlink (the first arg
FILENAME) should be interpreted as a filename for make-symbolic-link.

Another issue that might play a role is backward compatibility.  In
the past, Ange-FTP has interpreted the symlink target as a filename
in file-symlink-p.  Ange-FTP does not implement make-symbolic-link.


What do you think?
-- 
A preposition is not a good thing to end a sentence with.

Re: file-symlink-p for remote files?

[Kai Großjohann]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> It seems to me that the target of a symlink should either be
> interpreted as a string by both functions, or it should be
> interpreted as a filename by both functions.

More concretely:

Say that (file-symlink-p X) returns the string Y.  Say that the user
then deletes X.  Then I think that (make-symbolic-link Y X) should
"undo" the deletion of X.

Hm.

Oh!  I just looked at the source, and actually,
tramp-handle-make-symbolic-link groks both cases, of Y being a Tramp
name and of Y being a non-Tramp absolute name.

*blush*
-- 
A preposition is not a good thing to end a sentence with.

Re: file-symlink-p for remote files?

[Kai Großjohann]

I've just looked at the new code for file-chase-links.  It occurred
to me that it tries hard to deal with the problem that file-symlink-p
returns a string that might not work as a filename.

How about adding another arg to file-symlink-p which specifies
whether to return the link target as-is, or whether to return it as a
filename?

Then file-chase-links wouldn't have to deal with ".." itself; instead
it could just tell file-symlink-p to return a filename, and then work
with that filename.

It would be really easy in the file handlers to return either the
original string or a filename.  In Ange-FTP returning a filename
would amount to calling ange-ftp-replace-name-component, and in Tramp
it would amount to calling tramp-make-tramp-file-name.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-symlink-p for remote files?

[Richard Stallman]

    I confess that I'm rather surprised by this decision.  It appears to
    be inconsistent with another decision on make-symbolic-link that you
    took some months ago.

Alas, I don't remember that issue at all.
The question is, are they really inconsistent?

    It seems to me that the target of a symlink should either be
    interpreted as a string by both functions, or it should be
    interpreted as a filename by both functions.

I am not sure whether to agree.

What is the concrete issue as regards make-symbolic-link?  What is the
case in which there's a question about what is best for it to do?

Re: file-symlink-p for remote files?

[Richard Stallman]

    I've just looked at the new code for file-chase-links.  It occurred
    to me that it tries hard to deal with the problem that file-symlink-p
    returns a string that might not work as a filename.

Yes, and if you specify 1 for the new optional argument, you can get
the link target as a file name.

    How about adding another arg to file-symlink-p which specifies
    whether to return the link target as-is, or whether to return it as a
    filename?

That would mean moving this code into file-symlink-p.  It would be a little
cleaner as a spec, but it would be somewhat more work.

If you want to do it, ok.