Re: tramp (2.0.29); erroneous error message: File is a symlink to a nonexistent target

[Michael Albinus]

address@hidden (Kai Großjohann) writes:

> address@hidden (Kai Großjohann) writes:
>
>> I think this part of the patch means that (file-symlink-p
>> "/ftp:address@hidden:/foo") might return something like "/bar" instead of
>> "/ftp:address@hidden:/bar".
>>
>> But I think that "/ftp:address@hidden:/bar" is more correct.

When writing the patch for Ange-FTP I have been confronted with 2
different behaviours there: In ange-ftp-file-symlink-p, the whole file
name ("/ftp:address@hidden:/bar") has been returned. But in
ange-ftp-insert-directory, the result of file-symlink-p has been
expanded (assuming that simply the string the link points to is
returned).

Obviously inconsistent. And the documentation didn't clarify. So I
decided, that just returning the string would be the consistent
implementation. Reason:

- In case of relative links ("foo" -> "bar"), only the string is
  returned as well. So anybody using file-symlink-p cannot expect that
  the result can be used as-it-is.

- Tramp did return the string only as well.

Meanwhile it seems that RMS has clarified that this would be correct.

Nevertheless, I'm still confused. My proposed Ange-FTP patch has been
applied to the CVS head of Ange-FTP (thanx, Kai!). But: Tramp has been
changed last week to return "/address@hidden:/bar". XEmacs/EFS does the
same. And, also last week, Stefan Monnier has fixed the problem
mentioned first in Ange-FTP CVS branch EMACS_21_1_RC returning the
full qualified Ange-FTP filename.

What is the truth? And how to spread it over the sources?

Best regards, Michael.