Problem with newest release

[Voxen]

Hi,

I've just updated BC4 with the newest release : Version 4.0.5 (build 19480)

It produces an issue I didn't have since the first BC4 version (beta) I used: now when I synchronize local files with remote server (linux server), while they should be strictly identical, at next synchronization BC4 shows them having different file sizes!

Please see the attached capture. Before this capture I synchronized those files between my Mac and my server. Then I launched a new synchronization and it shows me the same files having different file size. So instead of saying "Nothing to sync" BC4 now shows me a list of files that are identical. If I compare them, as you can see on the first two files in my capture, it shows identical content.

I did not change anything it my synchronization profile, just updated the software and now I have this big issue.

Edit: I've just checked the real local and remote file sizes of those files and they are all identical, it's BC4 who shows wrong file size for the remote server (right panel in my capture). See Capture #2.

Thanks for help!

[Aaron]

Hello,

Thanks for the report. The files appear to have a different size after the transfer, but this doesn't show up initially? Only after restarting the comparison? Do they show after a Refresh or Full Refresh?

Why type of server are you connecting to? Is it an FTP server? If so, if you go to the Profiles dialog, is the server set to use Auto, ASCII, or Binary in the transfer tab? If it is using defaults, override and set to binary, then restart the application. Does this help?

[Voxen]

Aaron I edit my message and added another capture.

1) No it didn't show up initially
2) Yes it showed different size after the transfer (at next sync)
3) It shows after a refresh or full refresh
4) I'm connecting to a Debian server through SFTP
5) Edited my profile and switched from Default to Binary, saved and restarted BC4 => didn't solve the problem

Thanks for your help.

[Voxen]

If it helps, I've done a new synchronisation of those files and transferred all of them left to right (local to server).
The BC4 log says files have been transferred. But instead of the list clearing completely as it does after a sync, it still shows the files with question marks left and right (?).

[Aaron]

Hello,

Could you email us a copy of the log at [email protected]? We'd appreciate a few more details on the server/version, and if anything odd looking pops up in the log.

You can enable additional log options in the Options dialog -> Tweaks, Log section. And please include a link back to this forum thread in the email. Thanks.

[Aaron]

I should also clarify: switching to binary effects the Copy. Any files already copied in the trouble state would need to be re-transferred.

[Voxen]

I should also clarify: switching to binary effects the Copy. Any files already copied in the trouble state would need to be re-transferred.

Ok! This solved the problem. I switched to Binary and transferred the files back to the server and now they don't show as wrong file size anymore.

I don't know why it worked before this new release though.

Thanks for your help.

[Aaron]

We updated some of our behind the scenes SFTP support, however it isn't entirely clear why this behavior changed for you. That would imply that we were failing to detect ASCII before (falling back to binary), but with 4.0.5 began to 'successfully' detect ASCII and using it now. However, our detection algorithm didn't change between 4.0.4 and 4.0.5.

The reason for the ASCII transfer is to apply the host OS line endings to the file, so the file is viewable on Linux when transferred to a Linux remote FTP, or vice versa to Windows. This is why the file size changes; the line ending character is a different size. However, you then cannot use a timestamp/size comparison, so it is common to override this and transfer as Binary if the remote location is just a storage location, or if it is capable of parsing alternate line endings.

[brablc]

Wrong CRLF conversion (incorrect host OS detection)

We updated some of our behind the scenes SFTP support, however it isn't entirely clear why this behavior changed for you. That would imply that we were failing to detect ASCII before (falling back to binary), but with 4.0.5 began to 'successfully' detect ASCII and using it now. However, our detection algorithm didn't change between 4.0.4 and 4.0.5.

The reason for the ASCII transfer is to apply the host OS line endings to the file, so the file is viewable on Linux when transferred to a Linux remote FTP, or vice versa to Windows. This is why the file size changes; the line ending character is a different size. However, you then cannot use a timestamp/size comparison, so it is common to override this and transfer as Binary if the remote location is just a storage location, or if it is capable of parsing alternate line endings.

Hello Aaron,

I have just spent an hour wondering, how does it come, that local OS X LF file endings end up on Centos Linux as CR LF. It was working fine for me (4.0.2) and was not working for my colleague (4.0.5) both working with SFTP profiles. So I have updated to 4.0.5 and suddenly I have the problem too. So apparently BC4 now recognizes properly what is text file extension, but fails at detecting what is the remote host OS. Would be nice to see a fix.

[Aaron]

Hello,

There is a configuration change for your specific profile or all profiles in the Profiles dialog, select default or the specific profile, in the in the Transfer tab change the setting from AUTO to Binary. This would prevent the ASCII conversion (changing the line endings to the native OS of either side). Any previously transferred files would need to be re-transferred, or you can open a file and save/set the Line Ending.

[brablc]

Yes, I understand this quick fix, but would be nice to have it fixed in the app too.

[brablc]

It looks like problem has not been fixed in 4.0.6 release.

[Aaron]

Hello,

Would it be possible to get a test account to your FTP server? You can email us at [email protected]. The other users in this thread had actual Linux remote servers, so the program is behaving correctly when converting the line endings for them when in AUTO or ASCII transfer modes.

Update: I should clarify, that the line ending conversion should match the Host OS on each side of the compare. The expected default behavior would be to have an OSX line ending on a local OSX side, and a Linux line ending on the Linux FTP side. A copy command would then perform the conversion so that the file gets the host's line endings. To override this behavior, you can change to a Binary transfer, which preserves the entire file as-is, including line endings, when copying from either side.