UploadDirectory in ScpClient.Net

[Psilax]

I was testing the uploading of whole directories with ScpClient using the Upload(DirectoryInfo directoryInfo, string Path) function (ScpClient.NET.cs)

My example uploads c:\temp\configuration to /home/root
I was expecting to get the content of my local folder in /home/root/configuration
but it ended up in /home/root/root

What I think is the faulty line is
SendData(channel, string.Format("D0755 0 {0}\n", Path.GetFileName(path)));
I believe it should be:
SendData(channel, string.Format("D0755 0 {0}\n", directoryInfo.Name));

[drieseng]

I did some tests myself, and I don't see any issues.

I created the following local directory structure:

c:\temp\foo\file1
c:\temp\foo\file2
c:\temp\foo\sub1\file1
c:\temp\foo\sub1\file2
c:\temp\foo\sub2

I created the following remote directory:

/home/sshnet/test

I then used the following code to perform the upload:

using (var client = new ScpClient(connectionInfoFactory.Create()))
{
    client.Connect();
    client.Upload(new DirectoryInfo(@"c:\temp\foo"), "/home/sshnet/test");
}

I ended up with the following remote result:

/home/sshnet/test
/home/sshnet/test/file1
/home/sshnet/test/file2
/home/sshnet/test/sub1/file1
/home/sshnet/test/sub1/file2
/home/sshnet/test/sub2

Please share more about your local directory structure, the code you used to upload and the remote result.

[drieseng]

Not sure why I couldn't reproduce this issue before, but this week I stumbled onto this issue myself.
I submitted issue #128 for this.

This should be fixed in version 2016.1.0-beta1.
Please test and provide feedback.

[Psilax]

I'll try to test it today, sorry for the delay, but was hectic here at work the past months.

[Psilax]

It works, I had to change my function call because in the past i used something like:

UploadDirectory("c:\temp\configurationfiles", "/etc") and then expect it the folder to be created on the target, while the functionality actually is that it will copy the content of the directory instead of the directory .

[drieseng]

Fixed by issue #128.