The .NET assembly duplicates my local folder
This question is related to this one: https://winscp.net/forum/viewtopic.php?t=22585
I used WinSCP to download/upload files from/to a remote server using the SFTP protocol. The client recently switched to Secure FTP as they no longer supports the SFTP protocol. I changed the way I create the Session so I use Protocol.Ftp with all the other settings, such as the FtpMode and the FtpSecure parameters.
This is the C# code I use to bring the remote files locally:
The HostDownloadFolder is something like this: "/folder/subfolder/".
My LocalDownloadFolder is something like this: "D:\folder1\folder2\folder3\subfolder"
The "subfolder" in the remote path matches the "subfolder" on my local disk. In other words, my transfer methos grabs all the files from the remote folder and moves them locally, in a folder that has the exact same name as the remote one.
This worked just fine while I used SFTP. Now, that we moved to Secure FTP, the same code moves the files, but not where I used to receive them. Instead, the WinSCP assembly creates a new folder inside my local "subfolder" and this new folder has the exact same. So instead of receiving all the files in "D:\folder1\folder2\folder3\subfolder", The WinSCP creates a new folder like this "D:\folder1\folder2\folder3\subfolder\subfolder" and copies the files in there. Needless to say, this screws up the rest of the application that now needs to be reconfigured to look for the downloaded files in a different location.
Is it something that I am not doing right?
Any suggestion will be highly appreciated.
Thanks,
Eddie
In SFTP, the remote folder from which I was reading the files had a path that was terminated with a forward slash, something like this "/folder/subfolder/". Once I switched to FTPS, I started getting errors regarding the remote host, something along the lines of "can't get the attributes of file ..." because "file or folder '/folder/subfolder/' does not exist". That was weird. After I played with it for a while, I noticed that in the WinSCP application, once it connects to the remote server, the path is listed without the final forward slash. I changed it in my application as well (so now my remote folder is indicated "/folder/subfolder") and everything works fine.
The interesting thing is that the upload folder is still indicated as "/folder/uploadSubfolder/" and it's still working.
Can anyone confirm that this is the right thing I need to do or is it more to it and I just haven't figured it yet.
Thanks,
Eddie
I used WinSCP to download/upload files from/to a remote server using the SFTP protocol. The client recently switched to Secure FTP as they no longer supports the SFTP protocol. I changed the way I create the Session so I use Protocol.Ftp with all the other settings, such as the FtpMode and the FtpSecure parameters.
This is the C# code I use to bring the remote files locally:
// Setup session options
var sessionOptions = GetSessionOptions();
using (var session = new Session())
{
// Connect
session.Open(sessionOptions);
// check if any files are available for download
if (session.FileExists(HostDownloadFolder))
{
// transfer options
var transferOptions = new TransferOptions { TransferMode = TransferMode.Binary };
// download all the files
TransferOperationResult transferResult = session.GetFiles(HostDownloadFolder, LocalDownloadFolder, false, transferOptions);
// Throw on any error
transferResult.Check();
// Print results
foreach (TransferEventArgs transfer in transferResult.Transfers)
{
try
{
ConsoleProcess.TraceAndLogMessage(TraceMessageType.Report, string.Format("Download of {0} was successful", transfer.FileName));
// remove the file
session.RemoveFiles(transfer.FileName);
ConsoleProcess.TraceAndLogMessage(TraceMessageType.Report, "The file was deleted from the remote FTPS server.");
}
catch (Exception exception)
{
ConsoleProcess.TraceAndLogMessage(TraceMessageType.Error, string.Format("Failed to delete the {0} file from the remote FTPS server!", transfer.FileName));
ConsoleProcess.TraceAndLogMessage(TraceMessageType.Warning, string.Format("The error reported was {0}.", exception.Message));
}
}
}
}The HostDownloadFolder is something like this: "/folder/subfolder/".
My LocalDownloadFolder is something like this: "D:\folder1\folder2\folder3\subfolder"
The "subfolder" in the remote path matches the "subfolder" on my local disk. In other words, my transfer methos grabs all the files from the remote folder and moves them locally, in a folder that has the exact same name as the remote one.
This worked just fine while I used SFTP. Now, that we moved to Secure FTP, the same code moves the files, but not where I used to receive them. Instead, the WinSCP assembly creates a new folder inside my local "subfolder" and this new folder has the exact same. So instead of receiving all the files in "D:\folder1\folder2\folder3\subfolder", The WinSCP creates a new folder like this "D:\folder1\folder2\folder3\subfolder\subfolder" and copies the files in there. Needless to say, this screws up the rest of the application that now needs to be reconfigured to look for the downloaded files in a different location.
Is it something that I am not doing right?
Any suggestion will be highly appreciated.
Thanks,
Eddie
In SFTP, the remote folder from which I was reading the files had a path that was terminated with a forward slash, something like this "/folder/subfolder/". Once I switched to FTPS, I started getting errors regarding the remote host, something along the lines of "can't get the attributes of file ..." because "file or folder '/folder/subfolder/' does not exist". That was weird. After I played with it for a while, I noticed that in the WinSCP application, once it connects to the remote server, the path is listed without the final forward slash. I changed it in my application as well (so now my remote folder is indicated "/folder/subfolder") and everything works fine.
The interesting thing is that the upload folder is still indicated as "/folder/uploadSubfolder/" and it's still working.
Can anyone confirm that this is the right thing I need to do or is it more to it and I just haven't figured it yet.
Thanks,
Eddie
