Announcement

Collapse
No announcement yet.

Files not identical (binary folder compare) but change to identical after hex compare

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

  • Aaron
    replied
    A full refresh should re-compare everything, but since you are running into odd issues, what if you fully close bcompare and open it again (without changing any comparison settings), does this re-open and compare the same each time? If this is shifting, then switching comparisons would be an unreliable test and we should focus on shifting comparisons with the same configuration first.

    When performing CRC codes, if you also enable the CRC column, you could keep an eye on if either code is changing.

    If the folders are local, there shouldn't be any local temp file generation. This is a scenario more for working with remote folders.

    Viewing the picture files is only comparing visible picture information, and while we have a meta tab for header information, there could be other information within the file that is non-visible that would cause it to be rules-based equal but not binary/crc equal. The Hex Compare, however, I'd expect to match the binary/crc results.

    Leave a comment:


  • exces6
    replied
    Originally posted by Aaron View Post

    When comparing the folders, what are the base folder targets and what size is reported in the listing? Binary, for example, can short-circuit and report unequal with different sizes (since, if the size is different then it must be binary different). However, the rules-based scan should match the results if you double click and view the files in the default viewer.
    I'm running a folder compare on a base folder called iCloud Photos, the entirety of which was copied to the new drive. The contents are 5 folders, only one of which ("Downloads," the one with pretty much 100% of the data) results in a mismatch. The reported size of both is 200 GB.

    Originally posted by Aaron View Post
    Is the default viewer the Hex Compare when double clicking? If it loads a different viewer type, what does it show?
    The default viewer for .mov files is hex compare, the default viewer for .jpg files is picture compare (which shows two identical-looking pictures side-by-side as best I can tell).

    Originally posted by Aaron View Post
    If testing CRC, you can enable the CRC column to verify the generated CRC code. This differs, correct?
    Strangely no, the CRC values match.

    CRC-based:


    Originally posted by Aaron View Post
    When manually launching in to the Hex Compare, this runs a Rules-based scan using that viewer, which will update the center column with those results. I would expect the Hex results to be unequal if the binary scan were unequal, but downloading the file to a temp local file (again, assuming some kind of remote connection) might be triggering a conversion which is then causing the files to be equal (although, I'd expect similar behavior for the CRC scan in that case). If you copy the file using BC4 to a local temporary folder, does the temp version then binary match either the source it was copied from or the other aligned target? If you repeat copying with robocopy, which side does this temp version binary match?
    I tried to test this today but ran a full refresh before recording the files affected because most of them I had done the manual hex compare on, thereby resetting their values in Folder Compare. However, now (despite using the same BC4 session and not changing the settings), the files all match (binary, CRC, and rules-based comparisons). Is there a cache I need to clear to get a true reset? It seems strange that it would flag as mismatched some files one time and not on a second run.

    Also interestingly, running the comparisons on the same source and target but with the different types of comparisons showed different numbers of nonidentical files. The screenshot above is from the CRC comparison (and is only a sample), but the rules-based screenshot shows all non-identical files. Look at how many fewer (and seemingly non-overlapping files) it flagged as mismatched with the rules-based comparison. Sadly, I didn't grab a screenshot from the binary comparison before refreshing it, but it only had 5 files listed as non-identical, and since I didn't record the names I don't know if they were flagged with the other methods.

    Rules-based:
    Click image for larger version

Name:	rules run 1.JPG
Views:	102
Size:	54.6 KB
ID:	83673

    Regardless, a full refresh of all 3 methods now shows all files as identical, but I don't know if I should trust it or try making a fresh copy from scratch. Does a copy with BC4 include a verification step after copy?

    Thanks so much!

    Leave a comment:


  • Aaron
    replied
    Hello,

    When comparing the folders, what are the base folder targets and what size is reported in the listing? Binary, for example, can short-circuit and report unequal with different sizes (since, if the size is different then it must be binary different). However, the rules-based scan should match the results if you double click and view the files in the default viewer. Is the default viewer the Hex Compare when double clicking? If it loads a different viewer type, what does it show?

    If testing CRC, you can enable the CRC column to verify the generated CRC code. This differs, correct?

    When manually launching in to the Hex Compare, this runs a Rules-based scan using that viewer, which will update the center column with those results. I would expect the Hex results to be unequal if the binary scan were unequal, but downloading the file to a temp local file (again, assuming some kind of remote connection) might be triggering a conversion which is then causing the files to be equal (although, I'd expect similar behavior for the CRC scan in that case). If you copy the file using BC4 to a local temporary folder, does the temp version then binary match either the source it was copied from or the other aligned target? If you repeat copying with robocopy, which side does this temp version binary match?

    Leave a comment:


  • Files not identical (binary folder compare) but change to identical after hex compare

    Hi,

    I’ve been trying to move (copy and delete) a large cache of photos and videos to a new hard drive and verify the copy with BC4.

    When I run a folder compare, the majority of the 21k or so files are identical, but 5 or so are not as shown in the folder compare screen. However, when I select one of these not identical files and run a hex compare, there are no differences (using the diffs only filter), and after churning through the compare, the original folder screen changes to shows the two files as byte-for-byte identical.

    I have used CRC, binary, and rules-based comparison with similar results, and I’ve tried binary compare both with and without the attributes compare options. Also running a refresh seems to tag different files each time (though I haven’t thoroughly tested this). The flagged files are mostly .mov iPhone videos, with the occasional iPhone .jpg flagged.

    Does anyone know what might be going on? I copied the files using robocopy and the /MIR, /COPYALL, and /DCOPY:T flags, so all metadata and timestamps should be identical. Just trying to have the best possible copy before I delete the original folder to free up space. This is on BC4 4.3.4.

    Thanks!
Working...
X