Archived Forum Post

Index of archived forum posts


ResumeDownloadFileByName fails when local complete file already exists

Mar 24 '14 at 13:08

When trying to resume a download on a complete local file I get false as a return code. It fails because it expects the local file to be 0 in size after download !?!

Last error message from ChilKat:

ChilkatLog: ResumeDownloadFileByName: DllDate: Aug 15 2013 ChilkatVersion: UnlockPrefix: PATRIKSSH Username: SDCB190:sdcurda Architecture: Little Endian; 32-bit Language: .NET 2.0 VerboseLogging: 0 SshVersion: SSH-2.0-mod_sftp/0.9.7 SftpVersion: 3 PreserveDate: 0 fromFilePath: ./utbox/VO23012625_STYRSYSTEM_OK.hpr toFilePath: C:TempVO23012625_STYRSYSTEM_OK.hpr OpenRemoteFile: filename: ./utbox/VO23012625_STYRSYSTEM_OK.hpr access: readOnly createDisposition: openExisting v3Flags: 0x1 Sent FXP_OPEN handle: 325A616A4D61 timeToOpenMs: Elapsed time: 16 millisec --OpenRemoteFile FetchRemoteFileAttributes: filename: ./utbox/VO23012625_STYRSYSTEM_OK.hpr Using FXP_STAT Sent message to fetch attributes. Received SSH_FXP_ATTRS timeToFetchAttrMs: Elapsed time: 0 millisec --FetchRemoteFileAttributes remoteFileSize: 115471 resumeFlag: 1 startingLocalFileSize: 115471 Local file size is already equal or greater than remote file size closeHandle: handle: 325A616A4D61 Sent FXP_CLOSE StatusResponseFromServer: Request: FXP_CLOSE InformationReceivedFromServer: StatusCode: 0 StatusMessage: OK --InformationReceivedFromServer --StatusResponseFromServer --closeHandle Closing local output file... Verifying local output file size... localFileSizeAfterDownload: 115471 expectedFileSizeAfterDownload: 0 Local file size not equal to the expected size! totalTimeMs: Elapsed time: 16 millisec Failed. --ResumeDownloadFileByName --ChilkatLog


The documentation says: "If the localFilePath is already fully downloaded, then no additional data is downloaded and the method will return true."

It works every time if there is no local file.

Is this a bug, or am I doing something wrong?

Regards, Urban Dahlberg


Thanks. This is fixed. Here are the new builds:

32-bit .NET 2.0/3.5 Framework:

64-bit .NET 2.0/3.5 Framework: