Re: file-relative-name and remote files

[Kai Großjohann]

Richard Stallman <address@hidden> writes:

> I see that (expand-file-name "/address@hidden:/../emacs")
> returns "/address@hidden:/../emacs".  That is surprising;
> I expected it to return "/emacs".
>
> It would probably be easy to change this, and that change would
> probably fix the whole problem.  But was this done intentionally?
> Does it serve a specific purpose?
>
> If we don't change this behavior, then we do need to change
> file-relative-name.

In my mind, filenames are a forest, rather than a tree.  For me, the
name of a remote file is firmly separated into two parts: one part
that specifies the host, and another part that specifies the file on
that host.  So opening the file /address@hidden:/../emacs
should behave the same as logging in to the host galois, then opening
the file /../emacs there.  If galois is a Unix host, then /../emacs
should be the same as /emacs.  Therefore, (expand-file-name
"/address@hidden:/../emacs") should evaluate to
"/address@hidden:/emacs".  (It seems that Tramp has a bug in
that it fails to remove the "/.." part.)

I could not imagine in my wildest dreams that one could use relative
file names (in particular, using "..") to cross host boundaries.

Does this explain where the current behavior comes from?  (Modulo
that bug where expand-file-name fails to remove "..".)

But I see that it is wrong to assume that filenames are a forest.
Instead, it is right to assume they are a tree.

I will change expand-file-name so that "/foo:/../bar" is handled
correctly.

Btw, if the part after the colon is not an absolute filename, that is
interpreted as being relative to the remote home dir.  What happens
if I open a file "/foo:../bar"?  Is that the same as "/foo:/../bar"
and therefore the same as "/bar"?

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