I've been trying to figure out the issue with the SFTP transfer and don't seem to be able to find any possible solution. First of all - there are no problems during a connection established manually through Filezilla and such. I'm able to connect, navigate to the folder, upload. When I try to upload the file using rebex - I'm getting an exception when I call PutFile method on SFTP. You can find the example of my code below (nothing special there, and we have it running just fine for many other SFTP clients, with the exception of this particular one). I have also attached the logwriter to see if I can make any sense out of it. By looking at it (also included below) it seems that it fails during the close event, and that the file, in fact, did transfer successfully. Am I correct?
Any help would be appreciated. Thank you,
Here is just a small excerpt of my code:
And the piece of the log that I captured.
Applies to: Rebex SFTP
asked 12 Oct '12, 02:17
Yes, you are correct - first, the
In any case, it is very strange the same operation seems to work in Filezilla. Once an SFTP session is established, an upload of a 38-byte file is a very simple operation and the actual commands being sent should be the same. Unfortunately, Filezilla is unable to create a log verbose enough to actually show the commands. Would it be possible to try using WinSCP instead? It can create verbose logs and if it works as well, this would make it possible to spot any difference and change Rebex SFTP's behavior accordingly.
answered 12 Oct '12, 13:38
Lukas Pokorny ♦♦
Thank you for a quick response, Lukas. I just tried using the WinSCP and seeing a similar behavior when I just tried to upload a dummy file (see screenshot:
Below is a part of the log that I was able to obtain from the WinSCP
I'm not a pro at SFTP and not really sure what exactly is going on here, but am I safe to assume that it is the issue on the client's end? Do you know if the file, in fact, did transfer and error message only caused by attempting to close a connection? And if so - is there any way to overcome this in code (so it doesn't throw an exception). Or did the failure occur during the transfer?
The other interesting part I noticed in the log is this :
Could this be the reason for a failure? Thank you once again for your help. N
answered 12 Oct '12, 14:02
Thanks for update!
I would not assume the issue is on the client's end - two different SFTP clients (WinSCP and Rebex SFTP) encountered an identical issue, which strongly indicates this is actually a server-side problem.
I'm wondering why there was no error in FileZilla now. Have you checked its log? It's not very verbosem, but there still might be some information. It's even possible it encountered this error as well but ignored it.
SFTP protocol is actually a remote file system protocol. It doesn't have a single "transfer a file" operation (in contrast to FTP), but instead defines the following commands (among others):
An SFTP client actually opens the file first, then uploads the data, and finally it closes the file (this resembles .NET's
You might catch
This is not related to the issue. WinSCP reports this message for all servers using SFTP v3 by default, regardless whether there is a bug or not. The bug itself - if present - only means that "files on the server with timestamps before 1970 will be interpreted by WinSCP as times after 2038". See the end of this page for details.
answered 12 Oct '12, 15:52
Lukas Pokorny ♦♦