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.

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.

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'

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.

@Eugene:
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.

@Mykola:
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]
https://www.eldos.com/forum/read.php?FID=7&TID=2130
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.

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.

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.

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.

Eugene,
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.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.