Re: Tramp with shots

[Michael Albinus]

MIDI Lutescu <address@hidden> writes:

> Hi Michael,

Hi Mihai,

>     I tried unsuccessfully to debug the stuff, analyzed tramps logs, and
>     to make a long story short, no success.  Don't know until now what
>     was wrong with that system, or maybe with Tramp, or with me, or who
>     knows what.

I'm still interested in knowing what happened. Could you, please, set
`tramp-verbose' to 6, and rerun your test? When it fails, the debug
buffer might tell us more.

OTOH, you are using Ubuntu 10.04. IIRC, it offers Emacs 23.1, carrying
Tramp 2.1.15 (both released a year ago). I will release Tramp 2.1.19
next days, there are many bug fixes since then.

Could you, please, check, whether the problem still happens with Tramp
2.1.19-pre from CVS?

>     Sorry I meant 'maps silently' but I wrote 'mounts silently'. It's
>     the responsibility of the user to mount the remote file system.

I could imagine that your package offers different options: reuse
existing mount points, or mount silently if there is no mount point
available yet. This might be custom options.

>     Michael> And, secondly, it won't work for XEmacs. There is another
>     Michael> file name syntax for remote files; you would need to mount
>     Michael> at "/[ext/address@hidden/" - that's really ugly.
>     Michael> 
>
>     I used 2 simple functions, which make the translation
>     remote->to->local name and viceversa.  Changing them would make the
>     trick, I find not difficult this.

Of course. But I believe it is more elegant not to force a naming
convention for the mount point. The mount point could be anywhere, even
in the home directory of the user. Let's call it "/path/to/mount". Your
two functions would need to map "/path/to/mount/remote/a" ->
"/ext:address@hidden:/remote/a" etc. You simply must ensure, that 
"/path/to/mount"
is unique for every "address@hidden". Currently, you do it by naming 
conventions of
the mount point, but this is not mandatory.

>     I will look at tramp-gvfs.el.  On my Ubuntu 10.4 I have installed
>     tramp-gvfs.elc but not the source tramp-gvfs.el.gz, the `emacs-el'
>     Ubuntu package does not have it.  So I have to check out the sources
>     from CVS and look into.

Don't worry about all the D-Bus stuff, it's just used to speak to GVFS.

>     The relative symlinks do work.  The absolute one, don't (yet).  Thanks
>     for pointing me to this (looks like I encountered only relative
>     symlinks during these days).

It makes also difference, whether you let resolve the symlinks on the
local host, or on the remote host. See "-o follow_symlinks" of sshfs.

>     Michael> You also map the arguments of process calls - this might be
>     Michael> dangerous. Tramp avoids this for good reasons, and let the
>     Michael> caller do the right thing (the best guess is to use
>     Michael> relative file names as argument).
>     Michael> 
>
>     I do not totally understand the dangers you are talking about.  For
>     me was important to get remote compilation & grep & shell mode
>     working; don't think launching those kind of processes are
>     dangerous.  Maybe you could explain me.

You do not know, what clients are doing. Sometimes they do their own
mapping, sometimes not. Sometimes they use relative file names (that's
always good), sometimes absolute file names. And there might be even
arguments to processes, which look like a file name you intend to map,
but it isn't desired. And what about the result of remote processes?
You would need to map the resulting file name, when somebody calls "pwd".

In order to avoid confusion, it's best to have a simple policy: Tramp
does not map file names in arguments and results of remote processes;
it's the responsibility of the caller.

>     Michael> I'm happy for every volunteer. But please keep in mind,
>     Michael> that Tramp is copyrighted by the FSF. This requires for
>     Michael> every contributor of non-trivial changes to sign the legal
>     Michael> papers of the FSF. Would you be willing to do so?
>     Michael> 
>
>     But of course.

Great! Maybe you start reading 
<http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html#Copyright-Papers>.
I will send you the template off the list.

>     I apologize for this too long post,
>     Mihai Luţescu

Don't worry. Best regards, Michael.