Eli Zaretskii <[EMAIL PROTECTED]> writes: Hi Eli,
>> For openssh like implementations, I've (tried to) fix(ed) it by adding >> ControlMaster/ControlPath arguments to the "scp" commands. AFAIK, >> these arguments are not available under w32, so it shall be checked >> whether "pscp" is still the preferrable default method. > > I checked this now: on Windows, pscp behaves like scp and plink > behaves like ssh on Posix platforms. In other words, we should indeed > change the default method on w32 to plink, because that is faster and > asks for the passphrase fewer times. That was the default until recently. It was changed because people regard ssh (aka plink) methods too slow for copying large files. >> Of course, one would be on the safe side when PuTTY's pageant is >> running (the ssh-agent pendant). Maybe one could check this during >> initialization, and set tramp-default-method to either "plink" or >> "pscp", depending on the result. > > I will try to see if this can be done easily from within a running > Emacs. Please do. I hoped it could be determined simply via the existence of environment variables (as it is possible with ssh-agent, environment variables $SSH_AUTHENTICATION_*), but it doesn't seem so easy. And I also don't know a command like 'ps' which returns running processes, in order to check whether pageant is active. > Btw, why does pscp method work so hard when pageant is not running? I > see a lot of activity, including remote shell setup, remote `ls' > command to get a directory, sending Perl scripts to the remote > machine, etc. Why doesn't it simply invoke pscp to copy the darn > file? Is it for file-name completion, perhaps? if so, maybe we should > give users a way of disabling completion? All Tramp methods provide a whole implementation of primitive file operations. Not only for `copy-file' or `rename-file', but also `file-attributes' or `directory-files' etc. Those functions cannot be implemented by (p)scp, I fear. Because of this, Tramp opens additionally an ssh resp. plink connection. Best regards, Michael. _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
