Binary compare reports false positives

Create issue
Issue #18 resolved
KernelLeak created an issue

After retagging quite a bit of my FLAC files I've been trying to use WinMerge's Quick Contents mode (since FLAC stores the metadata at the beginning of the file) to compare my local files to the ones on my Linux server (served via Samba), but it found way more different files than there should have been.

For example, taking a single directory that's 100% identical (because I just copied it over by hand, and I've compared md5sums) WinMerge reported 11 differences (all the FLAC files) while only folder.jpg was seen as identical - see attachment...

Comments (13)

  1. jtuc repo owner

    If you doubleclick on a false positive, does the binary editor show a difference?

    ( If the binary editor doesn't work for you, run the Frhed-1.6.0-Setup.exe from )

    Edit: Not sure if this is relevant, but I just read about possible random disconnect issues with samba. A potentially relevant difference between quick and full mode is that quick mode alternatingly reads portions from involved files. Could be that spontaneous disconnects are somewhat more likely in that situation.

  2. KernelLeak reporter

    Sorry, I should have mentioned that in my first post - no, it didn't show a difference (or at least "Next Difference" doesn't jump anywhere).

    I don't think it's Samba, as doing the exact same thing via lighttpd's WebDAV support yields exactly the same result.

    Also, I think there's something genuinely broken with the comparison of large binary files, as just taking a FLAC folder on my local data drive, copying it two times to different locations and then comparing those two will tell me the binary files are different, no matter if it's a quick or full compare...

    Hope this helps tracking down the problem.

    EDIT: FWIW - the latest "original" WinMerge release takes a lot longer to compare the files (no matter if quick or full contents), but it reports the files as identical.

  3. KernelLeak reporter

    With the filter disabled - same thing.

    With the files in C:\Temp instead of F:\FLACs - same thing.

    With Microsoft Security Essentials disabled - same thing.

    According to procmon, it stops reading each of the 10 FLAC files at a different offset (when "Stop at first difference" is checked - why it would continue looking if it only displays "*" as number of changes is beyond me, though); but even if I set the quick compare limit to 1MB it happily reads more than that (up to 7MB for one file) before finding a "difference".

    Just for kicks I made a hex dump of two copies of one of the different files, and - no surprise - WinMerge told me those two 117MB text files were identical...

  4. jtuc repo owner

    Strange. I have no idea how to track this down. Would you mind to post the Help > Configuration report?

    Another odd thing is that your screenshot shows an asterisk beside the left date, although both dates are identical and it's not April 1st.

    Just to be sure - the SHA-1 checksum of my apparently working copy of the WinMergeU.exe is a489a67cfd7d702386d1c5642de2d437c363a3aa.

    Folder virtualization can also be a source of surprises, though I can't think of where that would come in to play.

    The quick compare limit means that files beyond that size will be handled by quick compare even if you select full compare. This is to reduce memory usage, as full compare loads entire files into memory.

  5. KernelLeak reporter

    I've attached the configuration report, and yes, the checksum checks out, and since I've got UAC disabled I rather doubt folder virtualization comes into play here, especially since I haven't installed it to "C:\Program Files (x86)\"...

    About the date thing - beats me, but afterwards I touch'd them all and they've been equal ever since.

    Also, seems like I was misinterpreting the meaning of "Quick Compare" - although I wouldn't mind a feature to limit the comparison to the x bytes at the beginning or end of all files.

    Do you happen to know if the source code can be built with Visual Studio C++ Express? I'm using Visual Studio Professional at work, but I don't have it installed at home, and I'd rather not lug my laptop back home to debug it...

  6. KernelLeak reporter

    Buh? Why would that even apply to a binary comparison, and why would it not work on two identical files? *wonders*

  7. jtuc repo owner

    There is no dedicated binary compare. Like full compare, quick compare is designed to deal with text. It looks for line endings and other whitespace, and is aware of character case, which enables it to support some of those ignore options.

    Changeset 6876c21909d3 is an attempt to fix the issue.

  8. Log in to comment