Same files showing as different?

[takabanana]

I've been trying to set up a diff between an FTP site's folder/files versus a local copy. Every time I start it up, it shows all the files as different, but once I double-click on the files, they show as equal.
How do I prevent this from happening? It also seems like it doesn't even do the actual diff until the files are double-clicked within BC. Thoughts?

Thanks.

[Chris]

By default Beyond Compare will compare files in the Folder Compare using timestamp and size. When you double click on files to view them, it compares their text contents and shows the text content comparison result in the Folder Compare.

From your description, it sounds like your files have a timestamp and/or size difference, but their text contents are the same. To make BC compare text contents in the Folder Compare without viewing each file in the Text Compare, select Session > Session Settings. Go to the Comparison tab. Check "Compare Contents" and select "Rules-based comparison".

[takabanana]

I *just* realized that the bottom half of Settings->Comparison says "Requires Opening Files" - is there ANY way I can get BC to automatically do a binary compare (that's how my Compare Contents is set to) for all the files in a folder view? It's a huge pain to have to open up one file at a time just to see if the files are different.

[Tim]

Actually, by "Requires Opening Files" we mean that the tests are slower because BC will need to (automatically) open files to compare their contents. You don't need to interactively open them one at a time. Perhaps we'll change that caption to "Slower Tests" to be less confusing.

You can follow Chris' suggestion and select Binary Comparison instead of Rules-base Comparison.

[takabanana]

Hi Tim -

Ah - ok. So it requires opening of files, but not manually... BC will automatically open them in the background.

But I *do* have it set to Binary Comparison - yet after it finishes the Quick Test - the Log window does not show the FTP session doing anything....
??

I basically have to open up each file one by one from the folder view to get them to be downloaded and shown as "equal" (or not, if they actually are different).

[Chris]

Turning on "Compare contents" and selecting "binary comparison" should compare the files and show the = or not = in the center column.

I've attached a screen shot of what your Comparison settings should look like.

[takabanana]

That's exactly what I have - and yes it does show the = or not = in the center column, but it seems to only base it off of the Quick Test. i.e. I don't see it (in the Log) downloading and doing a binary diff (it should definitely take longer). The last line in the log says "Background content comparison completed in X seconds"... but once I double-click on a pair of files in the Folder view (that I know are identical), it shows it as "= Same" - then once I close the file view, it changes the center column in the folder view for that file from 'not =' to '='.....

[Michael Bulgrien]

Opening the files in a text-compare session uses a Rules-based comparison, not a binary comparison. The files can be physically different (for example, one may have been saved with a different encoding than the other) and still show up as having the same content in the text compare (identical content based on the comparison rules for that file type). Opening a file in a text compare session will update the center column with the rule-based comparison results thus overriding the results of the binary compare.

FYI - You can also set your folder compare session settings to perform rules-based compares instead of binary compares.

[Michael Bulgrien]

Two files with identical content but different line endings (carriage return characters) would be another example of a difference that could be different in a binary compare, but the same in a rules-based compare.

[Chris]

The = or not = in the center column indicates a CRC, binary, or rules-based content comparison. The quick tests only indicate comparison results by coloring the file names.

If you're not seeing files being transferred in the log, it is possible they are cached. You can also change your log settings to be more detailed. To change logging, select Tools > Options from the menu, then go to the Folder Views > Log section.

[takabanana]

ok changing to Rule-based does compare the actual files... so a few Qs:

I would have thought, that the Binary-based would be most 'accurate' - showing differences whether the file is ASCII or binary?

I was specifically using this for PHP files on a web server via FTP compared with a localhost web server copy. I do not see rules defined for the PHP file type... how is it being treated?

Still don't understand why binary compare for PHP files would not show differences, if they really are different (i.e one script file had been updated; a line or two had been added).

I think in BC2 - I always used Binary compare for every file; it took longer, but was a lot more reliable than CRC (which would have a tiny chance of false positives) and obviously date/timestamp (which I do not rely on at all).

[Chris]

A binary comparison does a byte by byte compare of files, so it is the most accurate comparison type. The "rules-based comparison" compares the text content of files. It can ignore differences in white space, character case, comments, or line terminator type (Unix vs Windows) depending on the way you have your rules configured.

If there aren't defined file formats (in Tools > File Formats), then BC uses the default file format.

Also, when working with FTP sites, files can be transferred in binary or ascii mode, and this can affect the comparison. In ascii mode, text files have their line endings converted to the correct format for the platform if you are transferring from Windows to Unix or vice versa. In binary mode, line endings are not converted. BC defaults to selecting the transfer type based on file extension, but you can change the setting in Tools > FTP Profiles.

[takabanana]

I guess I dont know why Binary compare showed that they were equal (seemed to me that it did not even download the files from the FTP site to compare them until I double-clicked on the files - in which case they did a Rules-based compare from what you described and are telling me).

Any clues as to why, in Folder compare, Binary compare did not download the files from the FTP server for a Binary compare? Again, the files (at least in this case) were PHP files... and it seemed like it was just looking at timestamp, saying they were different in Folder view.

[Chris]

If the file sizes are different, binary compare will mark the files as different without downloading their contents.

If your PHP files were transferred in ASCII mode and the line terminators were converted, the file sizes would be different. This is because Windows uses two characters to terminate a line and Unix uses one character. The different file sizes would make binary comparison list the files as different without downloading them.

To avoid this, you can try changing the settings in Tools > FTP Profiles to force BC to always transfer files in binary mode.

[Dave W]

If the file sizes are different, binary compare will mark the files as different without downloading their contents.

If your PHP files were transferred in ASCII mode and the line terminators were converted, the file sizes would be different. This is because Windows uses two characters to terminate a line and Unix uses one character. The different file sizes would make binary comparison list the files as different without downloading them.

To avoid this, you can try changing the settings in Tools > FTP Profiles to force BC to always transfer files in binary mode.

Is the conversion of line endings covered elsewhere?
I am copying from windows server to PC (so I guess same endings) and then forwarding onto Unix system.
I see different file sizes for .txt .js and other file types yet for others the files are the same size.
Which setting do I need to ensure when copying Windows files to Unix the file endings ARE converted (having issues with perl scripts at the moment).