Today, we have spent several hours tracking down the source of crashes in our server software. The crashes started happening after a client connected to the server (using the SFTP protocol), opened (without modifying) some text files, and renamed them. Somehow, this has caused the files to be converted to UNIX line ending, even though the modification timestamps remained unchanged. As our specific (custom) software expected files to be in MS-DOS (CR/LF) line ending, this caused it to crash.
This situation is particularly embarrassing to me because I have personally recommended that the client abandon their existing FTP client software (mainly because it did not support encryption) and switch to WinSCP, which they did.
I recommend that the default transfer mode be changed to "binary" in WinSCP, with the following justification:
Reasons (known to me) why the default transfer mode should be "binary":
- avoiding accidental corruption of data when used in conjunction with software sensible to line endings (as in my anecdote above)
- compatibility with version control systems, file hash utilities, and other software that require bit-wise identity of data, even when the actual interpretation of the data has not changed
Reasons (known to me) why the default transfer mode should not be changed:
- compatibility with Windows Notepad.
Every other popular text editor known to me supports UNIX line endings. If changing the default setting is considered too drastic, I suggest prompting the user for the first time when a "text" file is transferred (perhaps when WinSCP detects a file association with software that is known not to support UNIX line endings).
A FYI (the following sounds like an attention-grabbing ultimatum, but I only intend to share my thoughts): If all suggestions are rejected, I can only conclude that WinSCP's project philosophy puts newbie-friendliness before data integrity. With that knowledge, I will no longer be able to recommend with good faith WinSCP to my clients.