tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tramp (2.1.11-pre); upgrade to gutsy and cannot open files on one se


From: Michael Albinus
Subject: Re: tramp (2.1.11-pre); upgrade to gutsy and cannot open files on one server
Date: Sat, 27 Oct 2007 16:15:31 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux)

Martin Flack <address@hidden> writes:

> Hi Michael,

Hi Martin,

> I downloaded CVS tramp and played with it. It still didn't work off
> the bat, but I figured it out. The localhost in the filename is
> causing tramp to try and "cheat" and copy the file with "cp -f" when
> it should be sending it in-band.
>
> The attached patch fixes the problem, by making tramp-local-host-p 
> return nil when there is a port specified. So ssh:localhost:blah will
> return t but ssh:localhost#3001:blah will return nil.

I understand your patch, but I don't understand why it is needed. The
introduction of `tramp-local-host-p' was driven by optimization,
operations shall run faster when being on the localhost. It is not clear
to me what's the difference when sshd runs on port 22 (the default) or
3001: In both cases, the files are located on the same place, with same
permissions. The optimizations for localhost shall either succeed or
fail in both cases.

The only difference when using another but the default port is the case,
when you have opened TWO connections to the same host in parallel, as
same user, but on different ports. This would confuse Tramp, because the
port number is not used for identifying the connection.

However, there were some other problems I've just fixed. Could you,
please, sync again with Tramp CVS and see whether you still have the
problem?  Btw, I've tested your configuration locally, and it works for
me fine (opening "/ssh:address@hidden:", misusing the account of
my wife :-).

> The only other solution I can think of is to introduce a configuration
> variable to govern the local-optimized behaviors, which would be
> another way to prevent the "cp -f" when it was not helpful.
>
> You may be able to come up with a better way to actually fix the issue.

If you still have the problem, I'ld like to see level 8 traces as before.

> Thanks,
> Martin

Thanks for debugging, and best regards, Michael.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]