Date:        Fri, 14 Nov 2003 14:27:50 +0300 (MSK)
    From:        Andrey Beresovsky <and@rsu.ru>
    Message-ID:  <200311141127.hAEBRow0001154@moon.cc.rsu.ru>


  | NetBSD's ftp client and ftpd server implement ASCII transfer type by
  | inserting <CR> before each <LF> without checking that may be <CR>
  | allready exists.

That is not a bug, it is what is required.

  | It leads to <CR><CR><LF> sequences in files

Only if there is something else broken, or you're transferring to a windows
type system, in which case that is what you should be getting.

  | which allready had <CR><LF> end of lines

No, in a unix file, <CR><LF> is never "end of line", the <LF> is.  A <CR>
that happens to precede the <LF> is just a data character.

It doesn't matter where the file came from, or why that extra CR is there,
once it is actually there in a unix file, it must remain there, until something
deliberately deletes it (which is certainly not FTP's task).

  | Attached patches should fix this problem.

No, they create a bug.

If I have a file with <CR><LF> sequences, and transfer it from one system
with that patch installed, to any other unix system, the file I will end up
with will have all the <CR> characters missing.   That means that FTP has
changed the file in transit, which is (would be) a bug.

  | >How-To-Repeat:
  | 1. Create a text file with <CRLF> end of lines.
  | For ftp:
  | 2. Send this file to ftpd server using NetBSD's ftp program (ASCII transfer type).
  | 3. You'll get a file with <CR><CR><LF> EOLs on windows and <CR><LF> on unixes.

Which is exactly what should happen.

Somebody please close this PR, without changing anything.

kre