Hi, I am using the licensed version of the 64-bit version of FTP2 and I'm encountering an odd problem.
Most of the files I use FTP for are on the smaller size, less than 500K. However, I have one that is about 8.3Mb and I'm seeing some odd behavior when downloading it from our Unix server and trying to place it on a shared network drive. It is truncating the last several Kb of the file. Setting the mode to Binary seems to correct this. But why won't it work in ASCII mode?
Here's the LastErrorHtml...
ChilkatLog: GetFile(733ms): DllDate: Jun 23 2015 ChilkatVersion: 184.108.40.206 UnlockPrefix: LUVATAFTP Username: GRDLT200:wsHTDFTP Architecture: Little Endian; 64-bit Language: .NET 4.0 / x64 VerboseLogging: 1 ProgressMonitoring: enabled: yes heartbeatMs: 0 sendBufferSize: 65536 AutoGetSizeForProgress: 0 downloadToFile(733ms): localFilename: c:\wutemp\ahl_oem_labels.txt Replacing existing local file downloadToOutput(733ms): ModeZ: 0 BinaryMode: 0 setupDataConnection: passive transfer mode setupPassiveDataSocket: sendCommand: sendingCommand: PASV readCommandResponse: replyLineQP: 227 Entering Passive Mode (10,29,185,44,191,139) commandResponse: 227 Entering Passive Mode (10,29,185,44,191,139) statusCode: 227 passiveHostAddr: 10.29.185.44 dataConnect: hostname: 10.29.185.44 port: 49035 socket2Connect: connect2: hostname: 10.29.185.44 port: 49035 ssl: 0 connectSocket: domainOrIpAddress: 10.29.185.44 port: 49035 connectTimeoutMs: 30000 connect_ipv6_or_ipv4: This is an IPV4 numeric address. Domain to IP address resolution not needed. connecting to IPV4 address... ipAddress: 10.29.185.44 createSocket: Setting SO_SNDBUF size sendBufSize: 262144 Setting SO_RCVBUF size recvBufSize: 4194304 connect: Waiting for the connect to complete... myIP: 10.29.186.126 myPort: 27276 socket connect successful. Setting SO_RCVBUF size recvBufSize: 8388608 socketOptions: SO_SNDBUF: 262144 SO_RCVBUF: 8388608 TCP_NODELAY: 0 SO_KEEPALIVE: 0 dataConnectS uccess: 1 sendCommand: sendingCommand: RETR /htd/p02/ifce/dat/out/ahl_oem_labels.txt readCommandResponse: replyLineQP: 150 Opening ASCII mode data connection for /htd/p02/ifce/dat/out/ahl_oem_la= bels.txt (8331750 bytes). commandResponse: 150 Opening ASCII mode data connection for /htd/p02/ifce/dat/out/ahl_oem_labels.txt (8331750 bytes). statusCode: 150 RETR_reply: 150 Opening ASCII mode data connection for /htd/p02/ifce/dat/out/ahl_oem_labels.txt (8331750 bytes). expectedSize64_2: 8331750 tlsDataConnection: 0 downloadRate: 11608378 totalNumBytesReceived: 8334816 receiveTimeMs: Elapsed time: 718 millisec readCommandResponse: replyLineQP: 226 Transfer complete. commandResponse: 226 Transfer complete. statusCode: 226 downloadToOutput: Elapsed time: 733 millisec MDTM is not supported by this FTP s erver. Cannot maintain the last-modified date/time automatically. TotalTimeMs: Elapsed time: 733 millisec Success.
My guess is the line endings are being converted from CRLF (Windows) to LF (Unix/Linux) during the ASCII mode transfer. BINARY transfers won't perform this conversion.
If you examine the "truncated" file, does all the non line-ending data appear to be there? If so, check if the line endings are now just LF instead of CRLF.