The problem is gone, and a co-worker pointed out a good way to fix this.

Set my transfer type to Binary, download the files. Use SubEthaEdit to convert all the line endings to Unix ones, then upload them binary. Afterwards, I should be able to set it back to automatic.

Yes!

Right as I connect, before the LIST command even goes to the server, the TYPE gets set to A.

What does this mean?

I just uploaded the file I downloaded using Cyberduck, and the line endings were preserved. I overwrote the file.

ie. i downloaded index.php with cyberduck (which locked up finder a few times) then uploaded it with yummy - and line endings stayed intact.

Here is the excerpt, if you want the entire thing, please just let me know.

...

SYST
215 Windows_NT
SITE DIRSTYLE
200 MSDOS-like directory output is off
SITE DIRSTYLE
200 MSDOS-like directory output is on
CWD /www/
250 CWD command successful.
PWD
257 "/www" is current directory.
TYPE A
200 Type set to A.
PASV
227 Entering Passive Mode (64,34,166,113,15,14).
LIST

...

I have Automatic set at the encoding method.

I am using FTP for both of the servers I am testing this against. SFTP on my Linux server does not have this issue. But then again, FTP with a Linux server doesn't have this issue either.

The suffix map shows that ASCII encoding is selected for the suffix in use (PHP).

Is it possible my old client (Cyberduck) was doing things in binary the entire time? Or am I missing a piece of the puzzle.

For some reason, whenever I connect to the FTP server running from IIS on a Windows Server, my line endings go away. I open files, and the entire thing is a single line.

My old FTP client... Does not have this issue. It shows the same files as having file endings.

When I connect to various Linux Servers, this is not an issue.

Recreating all the line endings is no fun.