EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SFTP component not connected error

Posted: 11/26/2009 07:53:21
by Jan Oud (Standard support level)
Joined: 11/02/2009
Posts: 4

I'm experiencing similar problems as discussed here
[URL=http://www.eldos.com/forum/read.php?PAGEN_2=3&FID=7&TID=2106#postform]SFTP component not connected error [/URL]
with some slight differences. I may connect to the server without problems. Yhis server identifies itself as an OpenSSH_5.1p1 Debian-5 server using sftp version 32 (sbSFTP5).
Uploading a file to the root ("/") using ElSimpleSFTPClient.UploadFile works perfectly. However, I need to upload my files to a folder named /incoming.
With ElSimpleSFTPClient.RequestAbsolutePath I request the full path (/incoming/) from the server, append the remote filename to the full path and call ElSimpleSFTPClient.UploadFile(LocalFileName, FullPath+RemoteFileName, TSBSFTPFileTransferMode.ftmOverwrite)
This keeps throwing the exception "SFTP component not connected". I tried the above mentioned suggestions regarding Piplining, AutoadjustTransferblock, Versions and Uploadblocksize but to no avail.
I've tried FileZilla and pSFTP and both work perfectly in both root and the /incoming folder. This rules out the possible lack off rights in the /incoming folder.

Any help is appreciated.
Posted: 11/26/2009 08:41:49
by Eugene Mayevski (Team)

Thank you for detailed description of the problem. As the upload works sometimes, this means that the problem is specific to the path being used. Do you have possibility to check the log of the server after unsuccessful upload attempt? Maybe it can shed some light to this strange problem, cause I don't see what exactly can be the root of such strange server behavior.

Sincerely yours
Eugene Mayevski
Posted: 11/27/2009 03:52:44
by Jan Oud (Standard support level)
Joined: 11/02/2009
Posts: 4

I just received the log from the server with, I think, some interesting information.
Uploading a file to the rootfolder shows as follows:
[16579][User][xx.xx.xxx.xx]Start upload into file '/dataset.dat'
[16579][User][xx.xx.xxx.xx]End upload into file '/dataset.dat'

But uploading a file to the /incoming folder results in:
[16939][User][xx.xx.xxx.xx]Start download file '/incoming/dataset.dat'
[16939][User][xx.xx.xxx.xx]End download file '/incoming/dataset.dat' : 0%

I highlighted the parts I find strange/interesting because in both cases uploaded a file, I just changed destination folder.

Additionally I can Inform you that I also tried the ElSimpleSFTPClient.write() method, although unsuccesfull it dies in a different way. I obtain a filehandle with .OpenFile(FullPath+RemoteFile,fmOpenOrCreate, New TElSftpFileAttributes). No problems there, pSFTP even shows me 0 sized FullPath+RemoteFile so I have Create rights. So next I execute a .Write(fileHandle, 0, sData) where sData is just a four byte teststring. There follows a ElSimpleSFTPClient.OnProgress event with as expected the parameters Total and Current both with a value of 4. After a ElSimpleSFTPClient.MessageLoop even the following exception is thrown: "No such file".

I don't know is it's usefull but I'm working with a : WinXP-x64, VB.Net 2008, Framework 3.5 machine.
Posted: 11/27/2009 05:13:57
by Eugene Mayevski (Team)

Please pass Nothing as the third parameter to OpenFile. Passing empty attributes can cause problems with various servers. Passing Nothing (null in C#) means "use default attributes" to the server.

Sincerely yours
Eugene Mayevski
Posted: 11/27/2009 05:46:14
by Mykola Olshevsky (Basic support level)
Joined: 07/07/2005
Posts: 442

Hi. Just to check:
1. What FullPath+RemoteFileName looks like, i.e. is it a correct path?
2. Have you tried to upload with SimpleSFTPClient demo?
Posted: 11/27/2009 06:51:42
by Jan Oud (Standard support level)
Joined: 11/02/2009
Posts: 4

Passing Nothing didn't work either, same problem. I did try filling the TElSftpFileAttributes propery .Userwrite with True and setting .IncludedAttributes to SBSftpCommon.Unit.saOwner, same problem.

FullPath was obtained by a RequestAbsolutePath. The serverlog also shows that I'm trying to write in the correct folder, also acknowledged by the server-owner. The SimpleSFTPClient demo "dies" in exactly the same way. I forgot to mention that, sorry.

But now to the good news: I solved the problem. Tom Marshall's line "We now perform the open command with just 'fmWrite' and 'fmCreate'" in this post
[URL=https://www.eldos.com/forum/read.php?FID=7&TID=2130]Can I upload a file without the 'Truncate' flag?[/URL]
got me thinking. I tried experimenting with TSBSftpFileOpenModes. Initially I used just fmOpenOrCreate assuming that would be enough. Finally though, with SBSftpCommon.Unit.fmCreate Or SBSftpCommon.Unit.fmWrite I had succes. I requested the serverlog and I could see that where previously a download was logged had changed in an upload.

[17337][User][xx.xx.xxx.xx]Start upload into file '/incoming/dataset.dat'
[17337][User][xx.xx.xxx.xx]End upload into file '/incoming/dataset.dat'

So far all's well,

This does imply however that the method .uploadfile -at least to this server- still doesn't work.

Thanks for your effort.
Posted: 11/27/2009 07:22:55
by Mykola Olshevsky (Basic support level)
Joined: 07/07/2005
Posts: 442

So, the reason is in file attributes.
Probably, that's why .UploadFile doesn't work - it calls .SetAttributes, which can be denied by the server.
This can be because of access rules for /incoming directory - probably, you are allowed to write there, but not to change file attributes.
Posted: 11/27/2009 07:23:17
by Eugene Mayevski (Team)

Default flags for UploadStream in ftmOverwrite mode is "fmCreate or fmWrite or fmTruncate". So your message means that removal of fmTruncate did the trick for you.

The problem with making the flags configurable in the component is that different set of flags is used for different modes. If you use just fmCreate or fmWrite (without truncate) and the file exists, the behavior of various servers is unexpected - some can open the file for appending, another will refuse to do anything (returning error) etc.

So I am having hard time figuring out what the proper strategy should be in this case.

Sincerely yours
Eugene Mayevski
Posted: 11/27/2009 07:28:54
by Eugene Mayevski (Team)

Mykola Olshevsky wrote:
Probably, that's why .UploadFile doesn't work - it calls .SetAttributes, which can be denied by the server.

Yes, just an idea - please try using UploadStream method and let us know if it works. If it does, then the problem is in SetAttributes. If it doesn't, then the problem is in Truncate flag as I mentioned above.

Sincerely yours
Eugene Mayevski
Posted: 11/27/2009 08:01:45
by Jan Oud (Standard support level)
Joined: 11/02/2009
Posts: 4

I tried Uploading the file (same name and destination folder) using the uploadstream method and this also results in the starting exception "SFTP component not connected error". So the truncate flag is the culprit I suppose.
I'll jus continue the way I have it working now. The host has a service active wich will remove my uploaded file and before uploading I already check if there is a similar file present and if Yes I'll take the appropriate action.

This would be sufficient wouldn't or I am I overlooking something?

Once again thanks for the help.



Topic viewed 5187 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!