bug#21562: Fwd: bug#21562: 24.5; Copy dir via Tramp pscp does not work

[Warren Lynn]

Hi Michael:

Here is I am resending the message you missed. Thanks.

Wanrong

---------- Forwarded message ----------
From: Warren Lynn <wrn.lynn@gmail.com>
Date: Tue, Oct 6, 2015 at 11:57 AM
Subject: Re: bug#21562: 24.5; Copy dir via Tramp pscp does not work
To: Michael Albinus <michael.albinus@gmx.de>

Hi Michael:

 

Thanks a lot for testing it out. On my Windows setup, I don't have the "test" directory under my Emacs installation directory (which is simply an unzipped directory from the official download). Where do I get it?

 

On the other hand, my test case is really simple. I don't have any fancy path names (no special chars and etc). Just something like this:

source:

/pscp:root@10.81.100.225:/mnt/Data_drive/wlin/ttt

destination:

c:\wlin\

 

Or reverse source/destination.

 

On Windows testing. One of the great things about Emacs is its versatility. It works on Windows and Linux, with either text termimal or GUI. Over the years, I have been bouncing between Linux and Windows (Windows is my main platform for the moment) and I feel I made a good and smart investment on Emacs. I hope the Emacs team does not treat Windows as the second priority and hence slowly lose one of its great strengths. Of course as you said, this all depends on the participation of the community. If you need some testing help on Windows, and it does not takes a lot of time (assuming most of it is automated), I can volunteer.

 

On Fri, Oct 2, 2015 at 1:59 PM, Michael Albinus <michael.albinus@gmx.de> wrote:

Warren Lynn <wrn.lynn@gmail.com> writes:

Hi Warren,

> Actually, things were more broken than I thought. The original code
> did not handle correctly directory copy from local to remote either.
> The reason is function
> tramp-make-copy-program-file-name
> already quotes the target, and then shell-quote-argument quotes the
> target again, so we get double quotes.
>
> I attached a second patch to fix both copying dir from local to
> remote, or remote to local. However, I am not so sure if this is a
> completely correct fix as I don't know much about the "multi-hop"
> thing. Anyway, hope this can serve as a starting point for the
> ultimate proper fix.

Thanks for your investigations.

I've applied your patch to recent Tramp sources, and the Tramp test
suite still passes all expected tests. That's good, but it's with a
local Ubuntu stanza.

Since I don't use MS Windows, I cannot check it for your case. Could
you, please run the test suite, preferred with and without your
patch. You could do this like this (untested):

set REMOTE_TEMPORARY_FILE_DIRECTORY=/pscp:user@host:/tmp

"C:\Program Files\emacs-24.5\bin\emacs.exe" -Q -batch -l "C:\Program Files\emacs-24.5\test\automated\tramp-tests.el" -f ert-run-tests-batch-and-exit

Of course, you must adapt some paths in this example.

Since nobody has reported such a problem yet, I suspect that your use
case is not covered yet by the Tramp tests. Could you please describe
exactly, what and how you have tried to copy, especially source and
target paths? I would like to get this problem reproducible. Well, for
this I need to hijack the laptop of my wife :-)

> BTW, all the above works out of box on Emacs 23.3.
>
> To be honest, I am quite disappointed with Emacs recent (last 2 or 3
> years) release quality. Seems some convoluted low-quality code was
> checked in the first place, and then not enough testing was done
> before release. Don't know if I have any right to complain in the
> first place as I am not an active developer here. But I would hate to
> see my favorite editor Emacs going down this path further.

I cannot speak for Emacs in general. But none of the Tramp contributors
uses MS Windows locally, as far as I am aware of. If there won't be any
volunteer for testing this, we cannot expect a better quality.

Additionally, the Tramp tests on MS Windows require special settings
(see %REMOTE_TEMPORARY_FILE_DIRECTORY% I've shown above). I have no idea
how we could establish a mockup Tramp connection method for testing, as
we have done it for local unixoid systems.

Best regards, Michael.

PS: Starting on Monday, I'll be offline for about a week.