The function dostor() in pure-ftpd-1.0.20/src/ftpd.c makes wrong assumptions about the behaviour of stream sockets on close() .  

In the event that a client is uploading a file to pure-ftpd (a "put"), if the client close()s the data connection and very quickly afterwards sends a command on the control connection, pure-ftpd will treat that as if a command had been sent on the control connection _during_ a data transfer, and will abort the transfer.

The underlying problem is that close()ing a stream socket, even with SO_LINGER, doesn't wait until the remote _application_ has finished reading, but merely until the remote tcp layer has ack-ed the shutdown.  So an ftp client can successfully close() the data connection while the ftpd is still reading data from the buffer on the remote machine.

The relevant mistaken code in pure-ftpd-1.0.20/src/ftpd.c is in dostor() at around line 3688 :

         if (xferfd == -1 ||
             select(xferfd + 1, &rs, NULL, NULL, &tv) <= 0 ||
            FD_ISSET(0, &rs) || !(safe_fd_isset(xferfd, &rs))) {

A better implementation, which will ignore the fact that the control connection has readable data _as long as_ the data connection doesn't block (and so will deal correctly with the case described above, while still correctly handling the situation where an ABORT is sent in the middle of a data transfer), is:

        if (xferfd == -1 ||
             select(xferfd + 1, &rs, NULL, NULL, &tv) <= 0 ||
            (FD_ISSET(0, &rs) && !(safe_fd_isset(xferfd, &rs)))) {

Note that the almost identical way of handling things in the doretr() function is entirely safe, since a client can't finish reading from the data connection until after the server _knows_ that it's finished writing!  So it's only the dostor() case that's dodgy.

I've marked this as a "critical" bug because it does cause silent loss of data in the event that an ftp client sends a QUIT immediately after closing its data connection on an ftp put.  My apologies if I've incorrectly determined that "Network" is the right "Component".

I should briefly note that I established the bug and tested the fix on Suse 9.* machines, but that inspection of the code on Suse 10 indicates that the problem has not been fixed in the interim.