I am connecting to an FTP server to download some gzipped files and I noticed something a bit disconcerting about the SIZE command and my google-fu has failed me.

ftp> size file0001.xml.gz
213 2524751

ftp> nlist -ltr
-rw-r--r--   1 anon  anons    2515727 Jan 30 00:00 file0001.xml.gz

The file sizes are different, (2524751 != 2515727), as you can see. Why?

I've briefly read the RCF0959 FILE TRANSFER PROTOCOL (FTP) and there's no mention of the SIZE command, which I later found out to be a non-standard addition to the protocol.

Here's the bit about byte size, for convenience, from the RFC:

  byte size

     There are two byte sizes of interest in FTP:  the logical byte
     size of the file, and the transfer byte size used for the
     transmission of the data.  The transfer byte size is always 8
     bits.  The transfer byte size is not necessarily the byte size
     in which data is to be stored in a system, nor the logical byte
     size for interpretation of the structure of the data.

What am I missing here?




Have you switched ftp into binary mode? ftp might be calculating the size with line-endings changed?

2524751 / 2515727 * 255 = 255.91469384396638

So it looks like every 255 bytes in the original gained 0.9 bytes extra - just enough for a compressed file to have \n converted to \r\n.

| improve this answer | |
  • Hey Douglas! Sorry for getting back to you so late. The problem was that type was indeed in ascii format, I was using it through python's ftplib. When I forced a retrbinary for size (retrbinary("RETR SIZE")), it worked like expected. Thanks! – Mahmoud Abdelkader Feb 5 '10 at 6:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.