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?



1 Answer 1


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.

  • 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! Feb 5, 2010 at 6:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .