Archived Forum Post

Index of archived forum posts

Question:

DownloadFile Hang?

Feb 12 '16 at 10:27

Hi,

I have an application built around the SFTP module that reads a series of directories on the server. Each directory has a pair of files in it. The app creates the same directory name on the local server, downloads each file to it and deletes the directory. Somewhere along the line, it appears to hang in the middle of a Download file command, usually when there are a lot of files to download (usually 200-400). If I restart the application it will get further, but may hang again or finally complete normally. I don't see a pattern in the number of files it downloads or the timing.

Capturing a log file gives me some clue that it is in the download file, but not sure how to proceed from here.

DownloadFile:
    DllDate: Jan  4 2016
    ChilkatVersion: 9.5.0.55
    UnlockPrefix: BADGERSSH
    Username: TM-REINARDY1:reinarjga
    Architecture: Little Endian; 64-bit
    Language: Visual C++ 12.0 / x64
    VerboseLogging: 0
    SshVersion: SSH-2.0-WS_FTP-SSH_7.6
    SftpVersion: 3
    handle: 3337
    toFilename: \mildoclibtsttemp01152016000970115201600097.XMQ
    tcpNoDelay: 0
    FetchRemoteFileAttributes:
        fetchAttributes:
            handle: 3337
            Using FXP_FSTAT
            Sent message to fetch attributes.
            sshReadMessage:
                (leaveContext)
            StatusResponseFromServer:
                Request: FXP_FSTAT
                InformationReceivedFromServer:
                    StatusCode: 4
                    StatusMessage: Folder not found: ToBadgermeter
                    (leaveContext)
                (leaveContext)
            (leaveContext)
        (leaveContext)
    Unable to get file size information from open handle.  Proceeding without the ability to monitor progress.
    IMPORTANT: The DownloadFile method expects a handle, not a filename.  The handle must have been obtained from a previous call to OpenFile.
    SFTP server did not provide remote file size.
    openForReadWriteWin32:
        (leaveContext)
    Reading until end of file...
    newDownloadLoop:
        socketOptions:
            SO_SNDBUF: 262144
            SO_RCVBUF: 4194304
            TCP_NODELAY: 1
            SO_KEEPALIVE: 0
            (leaveContext)
        startingOffset: 0
        numBytesToDownload: 0
        bReadUntilEnd: 1
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1901
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1902
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1903
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1904
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1905
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1906
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1907
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1908
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1909
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1910
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
        dataRequestStatus:
            reqId: 1911
            statusCode: 4
            statusMessage: End of File
            (leaveContext)
        sshReadMessage:
            (leaveContext)
  

This is truncated, but the DataRequestStatus ReqID increments, but otherwise these messages seem to repeat endlessly. I started with it in a schedule and it has gone all night without stopping. It should take just a few minutes. Not sure how to solve this, can you give me a clue?

Thanks,

Jim


Answer

Thanks.

There are a number of really strange things going on with this particular server.

  1. The DownloadFile method's first argument is a handle to an open file. The handle is obtained by a previous call to OpenFile. The only way you can get a handle is if OpenFile succeeded. Apparently, OpenFile succeeded (suggesting that the remote file is indeed present on the server), but when Chilkat tries to get file information (via the handle), the server responds with "Folder not found: ToBadgermeter". This is confusing because the handle should be a handle to a file, not a directory. Also, how can the remote file be "not found" when the server just opened it (via the call to OpenFile where it returned the handle). This is all perplexing...
  2. When the SFTP client requests data, and the end-of-file has been reached, the server should send an FXP_STATUS response in lieu of the actual data. Here are some status codes the server could send:
    (this is internal to Chilkat)
    #define SSH_FX_OK                            0
    #define SSH_FX_EOF                           1
    #define SSH_FX_NO_SUCH_FILE                  2
    #define SSH_FX_PERMISSION_DENIED             3
    #define SSH_FX_FAILURE                       4
    #define SSH_FX_BAD_MESSAGE                   5
    
    What your server is doing is sending an SSH_FX_FAILURE (status code 4) but with a status message of "End of File". For Pete's sake! Why in the world would the server do this instead of sending "SSH_FX_EOF"??? I have to say, this server is behaving very strangely.

I'll make a change so that "end of file" condition is caught with this wacky server's status response. I'll post the pre-release download URL once it's ready.

This should get rid of the infinite download loop, but it doesn't resolve the issue as to why the server successfull opens the remote file, but then says it doesn't exist..


Answer

Here are new builds that will hopefully stop the infinite loop:

32-bit Download: http://www.chilkatsoft.com/download/preRelease/chilkat-9.5.0-x86-vc12.zip
64-bit Download: http://www.chilkatsoft.com/download/preRelease/chilkat-9.5.0-x86_64-vc12.zip


Answer

Is it possible to get this in .dll form?


Answer

Yes, the .NET assembly. Thanks.


Answer

Here are the builds:

32-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet45-9.5.0-win32.zip

64-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet45-9.5.0-x64.zip


Answer

any timeframe on general availability of version 9.5.0.56 ? few years ago you have pre-release build generally available, it was an opportunity. (I'm using MS VC++ 9SP1 and 10 static lib and pre-release build are not available),

TIA


Answer

Here's a VC9 pre-release from yesterday:

32-bit Download: http://www.chilkatsoft.com/download/preRelease/chilkat-9.5.0-x86-vc9.zip
64-bit Download: http://www.chilkatsoft.com/download/preRelease/chilkat-9.5.0-x86_64-vc9.zip

It's not SP1, but an SP1 program should still be able to use the non-SP1 libs -- it's just not optimal. The next version will be released in the 1st few weeks of March. New releases come out approx. once every 2.5 months. Given that a new release involves so many platforms, operating systems, and programming languages, it can't be any more frequent.