You have tried to make that recommendation before and were told the same thing. If that were the case, reuploading as ASCII would be OK (subject to the following) as any existing CRLF pairs that got translated to CRCRLF sequences as part of the DOS conversion would just get converted back to CRLF. I was under the impression that going from Unix to Windows would convert every LF (including those in CRLF pairs already) to CRLF. Pony99CA wrote:I wanted to explore that a bit. If so feedback from users that binary is the more sensible default can help change developers' minds. With respect to what the default should be, maybe the developers don't want to break things for people who are happily transferring extensionless files in ascii mode. The second part was only relevant to client-server communication, not to what mode client chooses among the available ones. The first half of it was an explanation for why ascii would be the default. My previous post went a little too far into protocol details. I agree that a client is free to use any mode it is able to negotiate with a server.

If the server or client only offer one of the modes, then there is no choice but to treat it as ASCII. When in doubt, no transformations should be applied. If you're offering both and a mode called 'Automatic' that is supposed to do things magically without breaking files, it should try to be intelligent and not cause data corruption. Yes, I've read it, but that's really only a valid assumption if the client has decided to implement that single data type. If ASCII mode recognizes those, a binary file that happened to contain '1A'X would get truncated when converting to ASCII. I thought the real problem would be the DOS End-of-File character. Uploading it would convert both the new and the previous CRLFs to LF. Existing Line Feeds would have had a Carriage Return added in front of them, and existing CRLFs would have been left alone. “But can’t I just re-upload the files and let the line endings get converted back?” Unfortunately, no. The only option is to change the transfer mode and download them again if you still have access to the originals. NoxWizard wrote:Recovering the files is not possible at this point.

Sftp client for windows ascii