copy-file with two remote files behaves strangely

[Kai Großjohann]

I'm writing Tramp.  It's for remote files, similar to ange-ftp.  Tramp
users the filename format /address@hidden:address@hidden:/path/to/file.  `M' is 
a
method identifier which says how Tramp should access the remote host
and transfer the file.

Now, if (copy-file "/address@hidden:/foo" "/address@hidden:host2:/bar") is 
invoked,
the C function looks for a filename handler for the source file.  It
finds ange-ftp and hence ange-ftp-copy-file is invoked.  That function
parses the two file names and thinks that the source file is for user
`user' at host `host1', whereas the target file is for user `r' at
host `sm'.

One way to approach this is to change the Tramp file name format such
that ange-ftp doesn't think it's an ange-ftp file, anymore.  I haven't
tried what happens in this case.  I don't think that requiring
filename patterns to be nonoverlapping is the right approach, anyway.

Another idea would be to change copy-file, and perhaps the filename
handler interface.  Copy-file could find a filename handler for the
source file and a filename handler for the target file.  If they are
the same, a special function in that package is invoked for doing the
transfer.  If both files have filename handlers but the handlers are
different, copy-file could invoke file-local-copy on the source file
and write-region on the target file, effectively transferring the file
via a local copy.  If one of the two files is nonspecial, the filename
handler could be invoked with that information.

This seems to me like the right way to approach the problem, though it
requires changes in the infrastructure, rather than just changes in a
few packages.

Yet _another_ idea would be to change ange-ftp-copy-file to look if
the target file has a handler which is not the ange-ftp handler.  In
this case, it could do the via-local-copy trick, as described in the
previous paragraph.

This approach is nice because the basic Emacs code doesn't have to be
changed.  But every filename handler needs to be aware of the fact
that there might be other filename handlers out there.  It also leads
to redundant code, since every filename handler basically implements
the same logic.

Still another idea would be to find the first filename handler for
either the source or the target file.  (In case this somewhat short
description isn't clear: take the first entry in
file-name-handler-alist; check if the source file matches it, then
check if the target file matches it.  If one of them does, invoke that
handler, else proceed with the next entry in file-name-handler-alist.)

This way, `basic' filename handlers (near the end of the
file-name-handler-alist list) could be `stupid' whereas `advanced'
filename handlers (near the beginning of the file-name-handler-alist)
need to be `smart'.

Hm.  The above description is nice as far as it goes, but it probably
does not deal well with the really tricky cases.  In fact, I'm
thinking of writing a filename handler for tar files, so that you can
say C-x C-f /tmp/foo.tar/README RET to open the file README contained
in the tarball /tmp/foo.tar.  (I know of the package tar-mode.el,
which does not quite do this.)  I think it would be useful to design a
solution which can deal with this case.

So, imagine the following invocation of copy-file:

    (copy-file "/address@hidden:/foo.tar.gz/src/emacs.c.gz"
               "/address@hidden:address@hidden:/bar.tar.gz/new/foo.c.gz")

In the source file, the following filename handlers are involved:

  - ange-ftp for the /address@hidden part
  - auto-compression-mode for foo.tar.gz
  - the mythical tar filename handler for opening the file
    src/emacs.c.gz inside of the foo.tar tarball
  - auto-compression-mode for emacs.c.gz

Similarly for the target filename.

Can we design the filename handlers in such a way that the above
example works seamlessly?  It's a challenging task, I think.

(And what happens when the user opens the target file and then does
`C-x v v' on it?  Tramp supports remote VC, at least with RCS.  Oh,
boy.  It's clear what _should_ happen: a new directory new/RCS should
be created in bar.tar and the file foo.c,v (or foo.c.gz,v? or
foo.c,v.gz?) shold be created inside it.)

kai
-- 
~/.signature: No such file or directory