From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 Description of problem: FTP to updates.redhat.com from a Linux box. Neglect to set binary mode either because you forget or because you know that it SHOULD not matter (there should be no EOL conversion on unix-unix transfers). Grab an RPM. See how the received RPM is larger than that on the server. Watch rpm complain when you try to install it because it is larger than it ought to be. Do the same transfer using perl's Net::FTP package and see the same effect (so it's not an artefact of the client). Switch to binary mode, repeat and all is well. Either my understanding of RFC 959 et al. is borked or wu_ftpd is borked. Yes, it can be worked around. Remembering to select binary mode is one way (it's a shame ftp doesn't have a command switch so we can alias ftp so it switches to binary mode and it's a shame that .netrc doesn't seem to have any way of automatically selecting binary mode for specific machines or all machine). Hacking the perl mirror script by Felix Leitner is also possible (I would think that the mirror script ought to always select binary mode anyway). But wu_ftpd shouldn't be doing it in the first place. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Ftp to updates.redhat.com from a bog standard RH box. 2. Grab an RPM in ASCII mode. 3. Compare file size and/or try to install the RPM. Actual Results: Received file is too large. Expected Results: Received file should be the same size when transferring between two RH linux boxes whether ASCII or binary mode is used. Additional info:
this bug is not limited to wu_ftp... we are running into this on a server running redhat 7.3 which uses vsftp, and we are seeing the exact same behavior. Additionally, if we ftp from a windows box to this linux server and transfer a file in ASCII mode it works fine