Announcement

Collapse
No announcement yet.

Same files showing as different?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Aaron
    replied
    Hello,

    Thanks and yes, when you double click on an individual file, this is running a rules-based scan in the file viewer. Updating the folder compare to run a rules-based scan on everything would be like double clicking every file.

    "Skip content if quick tests" is usually disabled by default. It tells the program, if enabled, would skip the rules-based scan if the quick tests (timestamp/size) returned equal, as a way to avoid extra scanning if timestamp/size were enough in that scenario.

    This article may help as well: http://www.scootersoftware.com/suppo...ferentthensame

    Leave a comment:


  • jameschch
    replied
    I have used BC for several years and often had this problem with "invisible" file differences that disappear when opening the text comparison. Just found out that by switching to rule based comparison, disabling "Skip if quick test..." and and hitting ctrl+f5 (full refresh), the files that have invisible differences will no longer be marked as non-matching. This worked for BC3.

    Leave a comment:


  • Aaron
    replied
    Hello,

    The Transfer Type determines how the line endings of text files are handled. You can find more detailed information by searching "ascii transfer" in the BC3 Help file. You can add the perl's extension to the Tools menu -> FTP Profiles (will set for all profiles) under the Transfer tab.

    Or you can force ASCII transfers for all files in the Transfer tab of a specific FTP Profile.

    Leave a comment:


  • Dave W
    replied
    Originally posted by Chris View Post
    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).

    Leave a comment:


  • Chris
    replied
    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.

    Leave a comment:


  • takabanana
    replied
    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.

    Leave a comment:


  • Chris
    replied
    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.

    Leave a comment:


  • takabanana
    replied
    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).

    Leave a comment:


  • Chris
    replied
    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.

    Leave a comment:


  • Michael Bulgrien
    replied
    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.

    Leave a comment:


  • Michael Bulgrien
    replied
    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.

    Leave a comment:


  • takabanana
    replied
    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 '='.....

    Leave a comment:


  • Chris
    replied
    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.

    Leave a comment:


  • takabanana
    replied
    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).

    Leave a comment:


  • Tim
    replied
    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.

    Leave a comment:

Working...
X