List file by open returns a file to retrieve.
But cannot open the file. Would think that there is some sort of major disconnect on the server.
05/13/2014 08:47:35:readDirectory:OK  05/13/2014 08:47:35:Retrieving [first.csv] 05/13/2014 08:47:36:getFile:Error first.csv-D:\FTPDATA\ENTKSWEEP\first.csv.first  ChilkatLog: DownloadFileByName: DllDate: May 6 2014 ChilkatVersion: 188.8.131.52 UnlockPrefix: XXXBSSH Username: 2K3-GSFTP02:dbloader Architecture: Little Endian; 32-bit Language: Windows Perl VerboseLogging: 0 SshVersion: SSH-2.0-OpenSSH_4.3 SftpVersion: 3 downloadFileByName: PreserveDate: 0 fromFilePath: first.csv toFilePath: D:\FTPDATA\ENTKSWEEP\first.csv.first OpenRemoteFile: sftpOpenFile: remotePath: first.csv access: readOnly createDisposition: openExisting v3Flags: 0x1 Sent FXP_OPEN StatusResponseFromServer: Request: FXP_OPEN InformationReceivedFromServer: StatusCode: 2 StatusMessage: No such file --InformationReceivedFromServer --StatusResponseFromServer retryFilepath: ./first.csv remotePath: ./first.csv access: readOnly createDisposition: openExisting v3Flags: 0x1 Sent FXP_OPEN StatusResponseFromServer: Request: FXP_OPEN InformationReceivedFromServer: StatusCode: 2 StatusMessage: No such file --InformationReceivedFromServer --StatusResponseFromServer --sftpOpenFile timeToOpenMs: Elapsed time: 47 millisec --OpenRemoteFile totalTimeMs: Elapsed time: 47 millisec --downloadFileByName Failed. --DownloadFileByName --ChilkatLog
Please enter code and lastErrorText inside html <pre> / </pre> tags to make them readable.
The server is reporting "No such file" - are you sure the file exists at "./first.csv"?
If you pass a filename with NO directory path, then you are asking the SSH/SFTP server to open the file with that exact name located in the HOME directory of the SSH user account.
If the server responds "No such file" -- then it is NOT THERE.
If other applications seem to work, then it is because they are applications maintaining a conceptual/logical "current directory" and it MUST BE that when actually opening the file on the server, the app (such as FileZilla) is composing the full path.
Chilkat on the other hand is an API (not an application). The remote path you request is the exact path sent to the SFTP server. When you are using an application such as FileZilla, you have to be aware of the fact that your view of what is happening may not be exactly what the app is passing to the SFTP server. For example, if FileZilla says your current remote directory is "xyz" (and by the way, there is no such thing as a current remote directory -- in SFTP there is no state. You are never "in a particular directory") so.. if FileZilla says you are "in directory xyz" and you try to open "abc.txt", then FileZilla is ACTUALLY ending "xyz/abc.txt" in it's SFTP open request.
I open the folder, and get a list of files, then parse and build filename/path and try to open.
I always have these issue with mounted file systems and virtual folders.
The trick is to figure out what the path is, which I have not done.
I am also thinking that the real_path is not reporting the correct information, and therefore cannot build a path to that file.
Try using the sftp.RealPath method to get the SFTP server to tell you the real absolute path of a file. For example, you might call RealPath("test.txt","") and it might return "/home/chilkat/test.txt".
I have never thought to do what you have shown, maybe that will eliminate all the issues that I have with virtual paths.
Probably doing this in every circumenstance, will check that out.
My getfile was not right at all, got that to work.