EldoS | Feel safer!

Software components for data protection, secure storage and transfer

DownloadFile lock on empty file?

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#1290
Posted: 09/28/2006 14:17:20
by Jeff Lindborg (Basic support level)
Joined: 06/12/2006
Posts: 26

I'm running the most recent ActiveX version of the SFTP client and I just ran into an issue where using the .DownloadFile routine it will never return if the remote file is 0 length. I can add code to fetch the attributes and then determine if the size is 0 and then skip the download but this seems rather strange... is this a known issue?
#1292
Posted: 09/28/2006 15:19:14
by Eugene Mayevski (EldoS Corp.)

I remember that we fixed this bug some time ago, ut I am not sure if the fix got into 4.4 version.


Sincerely yours
Eugene Mayevski
#1293
Posted: 09/28/2006 16:41:47
by Jeff Lindborg (Basic support level)
Joined: 06/12/2006
Posts: 26

Well, I'm running 4.4.94 and I can reproduce this on demand so I'm guessing it didn't get ported.

I'm also noticing other instances where the Downloadfile routine just takes a nap and never returns to me. I cannot reproduce these other cases on demand however. Doesn't give me a warm fuzzy about the reliability of the control...
#1295
Posted: 09/29/2006 08:08:37
by Eugene Mayevski (EldoS Corp.)

The problem might be as well related to the server software. SSH (and SFTP) servers are very different from what the standards say. And from each other too.


Sincerely yours
Eugene Mayevski
#1298
Posted: 09/29/2006 09:43:11
by Jeff Lindborg (Basic support level)
Joined: 06/12/2006
Posts: 26

I kind of doubt this is a server side thing - We're using a pretty straight up deployment of RHES 4 here and other SFTP applications can transfer large numbers of files for hours on end without trouble.

Clearly the zero length file thing is your problem - can I get a fix for this?

Also, I was able to see about 15 to 20 times in heavy testing yesterday where the DownloadFile routine off your control simply never returns to me - it creates a zero length file on my local system which is then locked (i.e. I cannot copy, rename or delte it as a handle has it open) but the file itself never comes across. The file on the server is not empty and other attempts to get the same file work fine. After that your control is "burned" for good and I have to kill it and recreate it before it'll work again. Even if the server was not behaving properly I would expect your control to be a bit more resiliant with respect to handling error conditions than that.
#1299
Posted: 09/29/2006 10:14:27
by Jeff Lindborg (Basic support level)
Joined: 06/12/2006
Posts: 26

Follow up to this with some more testing this morning. What's actually happening is the call into SftpClient.DownloadFile is raising an error:

Catastrophic failure: -2147467259, source=SFTPBBoxCli.ElSimpleSftpClientX

and the next call into the control never returns, locking up the application and forcing you to have to kill it in the SCM.

I put in half second sleeps after each file copy before doing anything else (i.e. running UNIXTODOS on it prior to showing it in an editor). This makes it harder to reproduce but if I stick at it, it'll happen very reliably. Once the catastrophic failure occurs, the file it was attempting to copy is on the local box as a zero length file and it's locked.

Is there a debug version I can run to help you guys get to the bottom of this? This is at the heart of my file exporer function in my app and this is going to completely take the application out at the knees. I must fix this or find another means of transporting files.
#1300
Posted: 09/29/2006 12:08:58
by Eugene Mayevski (EldoS Corp.)

You are talking about ActiveX edition. This explains everything -- it's not the SFTP client code problem, but something ActiveX-specific. ActiveX has the only way to report the bug - the error code you mentioned: since VB doesn't handle other errors we are forced to return only the above one. I will forward your error message to the HelpDesk and the develoeprs will try to do something with this. Meanwhile, it's very important to reproduce the issue with the regular application. If the problem only happens in the services, then you need to review what's going on in them. BTW how are you using the ontrol - with VB or VC++ or something else?
Zero-length problem -- for now please test the size. The beta versions of SecureBlackbox 5 should solve the problem (if they don't now, the next build will do this for sure), but these are beta versions, which may have other problems, caused by the recent changes in the code.


Sincerely yours
Eugene Mayevski
#1301
Posted: 09/29/2006 15:10:10
by Jeff Lindborg (Basic support level)
Joined: 06/12/2006
Posts: 26

I'm using VB.

Not sure what you mean by testing in a "regular application" here - I'm not running as a service if that's what you mean.
#1304
Posted: 09/30/2006 02:52:50
by Eugene Mayevski (EldoS Corp.)

You mentioned SCM which is service control manager. That's why I thought about the service.

In fact, if you get an error, this doesn't necessarily mean the component error. This can be anything like lost connection etc.. You need to handle OnError event of ElSimpleSFTPClient to find out more about the errors. To avoid the error message box shown by VB you need to use On Error basic statement to catch and process the errors.


Sincerely yours
Eugene Mayevski
#1781
Posted: 12/05/2006 11:48:06
by Jeff Lindborg (Basic support level)
Joined: 06/12/2006
Posts: 26

Ok - follow up here. Your assumptions are incorrect - I am, of course, using error handling here - been doing this 15 years, kinda get how error handling works. You guys have a serious problem in your client stuff and a little effort into figuring out what is really going on would be good for both of us I think.

First, I'm running the latest ActiveX version: 4.4.94

Second, I AM doing error handling which is how I know what the error is in the first place. I've included a documeent with a snapshot of a dialog I pop up when a simple DownloadFile operation fails if you'd like to review it. The error number is -2147467259. In the dialog you see the path to the remote file and the local file I'm trying to copy it to.

This works sometimes. The SAME FILE will fail, and sometimes it works - there's nothing wrong with the file.

I am NOT copying an empty file - I already added logic for checking to see if it's empty or not to get around that bug in your control (this is not fixed). It's small text files (all under 200KB at most) that are causing these errors at times.

Once this error message comes up your control is burned and it will never work again - trying to force a close and a reconnect just results in more "Catastrohpic error" messages - there is no way it can be used again and you have to kill the entire application and start it again to get working again.

It appears to be a timing related issue in your stuff not being handled. If you go real, real slow and wait after each and every file copy event it seems to be stable - however if you hit it reasonably quickly it'll quickly burn the control.

Is there ANY debug information I can get to see what in the world is happening to your control under the covers that is throwing this error and burning it? This is getting pretty frustrating...

[edit - it would not let me attach a 40KB bit map or document with the dialog - trust me - it shows the local and remote file paths and the "Catastrophic error" message noted above]
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.

Reply

Statistics

Topic viewed 8366 times

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




|

Back to top

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

Got it!