Hi Michael: Here is I am resending the message you missed. Thanks. Wanrong ---------- Forwarded message ---------- From: Warren Lynn 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 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 wrote: > Warren Lynn 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. >