Re: `file-relative-name' for compressed files

[Kai Grossjohann]

Richard Stallman <address@hidden> writes:

> I don't want to study the code in detail myself.
> Kai, could you see if there is a clean way to fix Tramp
> to work with the existing framework?  If not, then we seem
> obliged to change the framework.

Thanks to Emilio Lopes who gave a list of test cases to consider.
Without that list, I would be unable to think about the issue -- it
has gotten rather complex and contains lots of sub-issues.  I have
snipped the cases he gave that work, and only retained the ones that
fail.

I have written, deleted, and rewritten this message multiple times,
but now it seems that there are two issues.  I will explain them
based on the test cases.

The following is based on the sources I checked out some hours ago.

Emilio Lopes writes:

> I've just updated and installed the lastest sources. From my
> test cases (with auto-compression-mode on) the following
> ones still fail:

>    (file-relative-name "/a/b/c/foo.gz" "/a/b/c/")
>    => "/a/b/c/foo.gz"
>    (file-relative-name "/bar:/a/b/c/foo.gz" "/bar:/a/b/c/")
>    => "/ssh:bar:/a/b/c/foo.gz"

The reason for the above to fail is the same -- the first arg is
compressed, so its handler is jka-compr-handler, which is different
from the handler for the second arg.  To fix this, jka-compr-handler
somehow needs to be ignored when determining the handlers.

Emilio has suggested to do this by explictly mentioning
jka-compr-handler in inhibit-file-name-handlers in file-relative-name,
and he also says that he is not happy about having to special-case
jka-compr.  

>    (file-relative-name "/bar:/a/b/c/foo" "/xyz:/a/b/c/")
>    => "../../../../ssh:bar:/a/b/c/foo"

This could be fixed by changing the file-name-handler-alist entry
from a short regexp to a longer one that matches the whole name
except for the localpart.

I do not know whether this will cause trouble elsewhere -- Michael
has mentioned that tramp-completion-file-name-handler is also involed
in some cases, which would break things.



Ignoring the tramp-completion-file-name-handler issue for the moment,
I see two ways to prcoceed.  The first way is based on local changes
only, the second way involves structural changes.

The local-changes-only alternative consists of changing
file-relative-name to ignore jka-compr when searching for a handler
(by incorporating Emilio's patch), and to change Tramp to use a longer
regexp in file-name-handler-alist.

The second alternative is to make file-relative-name into a file
operation.  Then jka-compr and Tramp can each do the right thing.

For Tramp, this means to check whether the file and the directory are
on the same host, and if so, to invoke file-relative-name on the
localparts of the filename and the directory.  I haven't studied
jka-compr in detail, but I _think_ that the right thing for jka-compr
is to do nothing.  The effect of doing nothing is that jka-compr calls
jka-compr-run-real-handler which disables itself and invokes
file-relative-name again -- this is what Emilio did in his patch, but
he put the code in file-relative-name.

In my opinion, the second alternative is cleaner.


Richard,

which solution would you like?  (If tramp-completion-file-name-handler
would still cause problems, then the local-changes-only alternative
would fail.)


Michael,

will tramp-completion-file-name-handler cause the local-changes-only
alternative to fail?

Kai