Subject: 2nd resend of ftpd bug

From: [email-masked] (Tim P. Starrin)
Date: Sat, 19 Oct 1996 00:20:41 -0400

I'm not sure if people are seeing this email, I haven't received any replies,
so I'm trying sending from a different host...

WU-ftpd-2.4 and probably earlier versions, appear to drop null bytes when
transferring binary files in ASCII mode.  Now, I'm sure many people would
react right away and say, "don't transfer binary files in ASCII mode".
However, shouldn't this work for some binary files anyway between like
Unix systems?
 
Using a 1-MB test file, I was able to successfully transfer it in ASCII
mode to AIX, SunOS, Solaris, UNICOS, and ConvexOS systems (using each vendor's
ftp server) and get the file back with no problems.
 
However, wu-ftpd drops null bytes while transferring files in ASCII mode if
they follow ^M's in some situations.  I have source code access to AIX,
UNICOS, and ConvexOS, and compared these sources to wu-ftpd.  None of
these vendor's ftpd.c's are coded to drop null bytes when they follow ^M's; 
however, wu-ftpd's ftpd.c is as follows...

--- ftpd.c, excerpt from receive_data() function ---
 
...
 
    switch (type) { 
...
 
    case TYPE_A:
        while ((c = getc(instr)) != EOF) {
            byte_count++;
            if (c == '\n')
                bare_lfs++;
            while (c == '\r') {
                if (ferror(outstr))
                    goto data_err;
                if ((c = getc(instr)) != '\n') {
                    (void) putc('\r', outstr);
------------------> if (c == '\0' || c == EOF)
                        goto contin2;
                }
            }
            (void) putc(c, outstr);
          contin2:;
        }
 
...

Note the line pointed to,  why is '\0' checked for here?  Shouldn't it be only
a check for EOF?  Anytime a ^M is followed by a '\0', the goto gets
executed and the putc of the '\0' is skipped.  None of the other ftp sources
I looked at check for the '\0' and skip it.  I think this is a bug.  If
it's not, would somebody tell me the real (and logical) reason why nulls are
skipped here?  Maybe it's just old leftover code that was supposed to cover
some EOF condition or some such?  The easy fix is to just remove the
"c == '\0' ||" portion of the "if" check.
 
96 bytes were dropped in my 1-MB test file due to this problem, essentially
corrupting the file.
 
Please reply as soon as possible - I'm ready to install some enhancements I've
made for our +2.5 million file hierarchical mass storage system and need to 
know how to proceed.  Thanks!
 
Tim P. Starrin (CSC)
DMSS Project Technical Lead
Project Systems Analyst / Computer Scientist
National Aeronautics and Space Administration

---

From: Lindsay Haisley <[email-masked]>
Date: Sat, 19 Oct 1996 00:00:08 -0500 (CDT)

Is this really a problem?  My understanding is that ASCII ftp mode was
developed to accomodate the different character representation and 
formatting conventions in use for text files on various systems from
mainframes to micros (such as the difference between Unix and DOS newlines). 
Since nulls are not signifigant in terms of Unix character representation,
it's probably a no-nevermind as to what's done with them, and in fact it
would seem to me to be more logical >not< to pass them.  I'm sure there must
be an RFC covering this somewhere.

--
Lindsay Haisley          | "Everything works     |   PGP public key
FMP Computer Services    |       if you let it"  |   available via
[email-masked]           |    (The Roadie)       |   Internet finger
http://www.fmp.com       |                       |