If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Files on the left contain changes that I want to copy to the right.
I click on the files that I want to transfer, right-click and select 'Copy to Right'.
The files are copied to the right, and now show no differences, (however the file on the right is larger than the left).
Inspection of the copied files on the target machine shows that all LF sequences have been changed to CR+LF sequences.

If you are copying to or from an FTP, the default transfer mode is Auto, which will convert the line endings to the destination OS line ending. You can change this setting in the Tools menu -> Profiles, select your profile, Transfer tab, and switch to Binary to always transfer without conversion.

There may be a problem with BC's ASCII transfer mode, as your explanation suggests that I shouldn't get line ending conversion when transferring between Linux machines. In this case, BC is running on Linux Mint 17.1 and merging files/folders between the home folder on the same machine, and an sftp connected Linux embedded PC running Ubuntu 12.04.4 LTS - so there should be no conversion.

Regarding the profile transfer settings: BC help says "The FTP server will automatically make any adjustments to line endings needed in ASCII mode", so this may suggest a problem with the FTP server on my embedded target rather than a BC problem.
To test this, I have edited one of the bash scripts on the embedded targed via sftp using the text editor on the Linux Mint PC, without any unusual end of line conversions; so this would seem to point the finger at BC.

Do you have access to another FTP client to test this connection? Such as Filezilla, which also has the Transfer menu, which can be set to Auto or ASCII to test the transfer. If this works, please email us a copy of the Filezilla log and a copy of the BC4 log with debugging enabled (in the Options dialog, Tweaks section, Log section). Our email is support@scootersoftware.com and please include a link back to this forum thread for our reference.

A quick thread update for anyone else having similar problems with changed line endings.

I sent BC and Filezilla logs to Scooter as requested above, and have received the following response:

Hello Dave,

Given the information in the ReadMe file, you should update your profile to switch from AUTO to Binary. Auto will convert certain line endings of specified extensions, which you do not want. To prevent this, always transfer using Binary. you can update the specific profile in the Profiles dialog, or also update the Default profile.

Any already transferred files will need to be re-transferred or converted (the Text Compare can convert line endings).

-Aaron Polans, Scooter Software

I have set Tools/Profiles/Transfer tab/Transfer type = Binary for all profiles, and have not had any problems with changed line endings since.

Translating the line endings is purposeful behavior for an ASCII transfer. The methodology is that you are on your Windows machine, editing a website that runs on a Linux FTP. When you transfer files up to the Linux FTP, an ASCII transfer changes the line endings to Linux, so that any Linux apps and the OS can read and handle the files. This is necessary in some cases for the website to then run correctly, otherwise they generate errors. With more modern solutions, this scenario is becoming less necessary; also if the Linux machine is just storage it generally isn't needed.

* Left side is on SFTP to a Linux server
* Right side is SFTP to the same machine
* Both files are correctly recognised as having UNIX endings
* My BCompare session is on my Linux desktop

BUT

* Saving either file writes the whole file with CRLF endings

That's really counter intuitive, given every platform in the mix is UNIX, the protocols being used for transfer are typically UNIX, and the files are UNIX.

Changed the default profile as suggested and it's OK again.

Honestly, I'd rather the default was not to mess with line endings. ASCII / Binary modes are a relic of the days when the 8th bit made a difference in transmit time. Most sensible editors OTHER than Windows Notepad can cope with LF endings. The only other tools I've used in the last 15 years that I noticed caring about them are VB6 (some VB6 files have MIXED line endings and hate it if you change them, so this kind of blanket tinkering would mess that up) and Bash (which hates CRLF files).

I started up an Ubuntu test machine running BC 4.1.2 64bit Linux application, and loaded a folder compare pointing to the same SFTP server based in Linux with two different accounts. If I load a child Text Compare on a pair of files, it detects as Unix line endings. I can edit and save, or copy the entire file from one side to the other, but AUTO (Ascii) preserves the Linux line ending in this case. Could you give a few more details on your setup? We will probably also need a full copy of your Log with debug messages enabled (Tweaks). You can post here or email us privately at support@scootersoftware.com with a link back to this forum thread.

The default mode is AUTO, which looks at the file extension to determine the method to use. Many FTP clients default to ASCII, as I mention earlier that a binary transfer would crash older web servers when these defaults were picked by various clients years ago. Changing the default for all users is something we've considered, but would probably not be updated in a minor release.

BC4 can be configured to have Binary as the default profile, which is then used for all profiles that do not override this setting. You can change this option in the Profiles dialog, and it will then be the default for you going forward.