openssh bugs - Dec 2004 - [Bug 941] Poor transfer from Windows to Linux

http://bugzilla.mindrot.org/show_bug.cgi?id=941

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From djm at mindrot.org  2004-12-06 17:08 -------
Sorry, but we won't implement workarounds for windows paths in portable
OpenSSH.
Instead, you can use the Cygwin 'mount' utility to eliminate the need to
use
them at all. See the documentation at:

http://www.cygwin.com/cygwin-ug-net/using.html



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=941





------- Additional Comments From david.outteridge at uchsc.edu  2004-12-07 03:31
-------
Comment #1 is a surprise to me.  Certainly I understand not implementing a
workaround; but I do not understand how this is a windows path workaround.

As I hope the example shows, a successful transfer from windows to linux
works, provided that the destination is the box running the scp command.  The
problem occurs when a third machine is identified, i.e., a remote windows to
*remote* linux transfer.

DESCRIPTION
     <snip>

     Any file name may contain a host and user specification to indicate that
     the file is to be copied to/from that host.  Copies between two remote
     hosts are permitted.

     <snip>

At this point I do not understand my own comment about special syntax, and it
seems that it only confuses the main issue, and should be ignored.

A workaround that I am using is simply to do two transfers: to and from the
scp host.  This suits my application better than using mount.

Thanks for looking at the (maybe not) bug report.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=941





------- Additional Comments From djm at mindrot.org  2004-12-07 09:09 -------
Actually this may be a cygwin bug. From your example:

scp  sourceid at windowsmc:c:/sourcefile  sinkid at
linuxmc:/a/directory/sinkfile
ssh: c: no address associated with name

It looks like something is intepreting the final 'c' and the two
following
characters as a Windows-style path. OpenSSH's scp certainly doesn't do
this, so
I expect that it would be Windows itself or one of the Cygwin DLLs that OpenSSH
links against.

What does turning up the debugging do. i.e "scp -v"



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=941





------- Additional Comments From david.outteridge at uchsc.edu  2004-12-11 02:31
-------
Here is the key output using -v.  There does appear to be something wrong with
the second exec of ssh.

scp-linuxhost-prompt> scp  -v  sourceid at windowsmc:c:/sourcefile 
sinkid at linuxmc:/a/directory/sinkfile
Executing: /usr/bin/ssh -v -x -o'ClearAllForwardings yes' -n -l sourceid
windowsmc scp -v c:/sourcefile 'sinkid at linuxmc:/a/directory/sinkfile'
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
<snip>
Executing: exec /usr/bin/ssh -v -x -o'ClearAllForwardings yes' -n c scp
-v
/sourcefile 'sinkid at linuxmc:/a/directory/sinkfile'
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh_config
ssh: c: no address associated with name
<snip>




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.