Archived Forum Post

Index of archived forum posts

Question:

Truncated file with FTP2

Sep 03 '15 at 09:20

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: 9.5.0.51
  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.

Thanks Tobin

---

Answer

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.