Version Compare interferes with File Compare

[Michael Bulgrien]

I was working with .EXE and .DLL files today (Build 445)
I knew some aligned files were the same, some were different (rebuilt).
All had different time/date stamps.

Unfortunately, things did not work very well. I had two problems:

1. When I compared the opposing folders, all of the files displayed as unique (I had Cirrus set up to compare contents with a binary compare, but not to compare versions). To get by problem I used the touch command to copy the date/time stamps from one side to the other.
2. After the touch command, all files displayed as equal and disappeared from the list. I had to recompare the folders to find the ones that were different.

I understand why the touch did me in (it was the "Skip if quick tests indicate that the files are the same" option) though I don't like that it happened. Had I not known that some of the files were different, I would have missed it in this compare exercise.

I don't understand why I could not identify the identical files without touching them. It was almost as if Cirrus was performing a version compare on the files and considering them different because the version compare includes date/time info???

Edit - What confuses me is that the first time I recompared the folders after the touch, only three files showed up as different. When I closed Cirrus and went back in a few minutes later, they all showed up as different again...so I'm not sure why I only saw three a few minutes before? I'll need to do more testing. I had done a replace in all files using another utility and did not have executables filtered out...so it very well may be that all the files were different after all. Part of the problem is that double-clicking the file pair now brings up a version compare session rather than bringing up the files in a view-only content compare, so I could not easily verify that the content had changed. I'll be happy when a binary (hex) compare session is added.

[Zoë]

Exes and Dlls have a "build on" timestamp embedded in them which will be different between two builds even if every other variable is the same. A binary comparison is going to pick that up. What it sounds like is that the builds generated otherwise identical files, so the sizes were all the same, but the filesystem timestamps and the embedded timestamps were different. When you first opened the directories the timestamps were different, which triggered the binary comparison, which would still mark the files as different. Once you touched everything, the size and external timestamps matched, so it skipped the binary comparison and just showed them as matching.

The version viewer would actually be better than hex for this case, but I think it's content comparison compares the entire file contents right now. To be the most useful we would have to make it skip the fixed and variable version fields and compare everything else. If the version info changed size it would change other values though, so it would have to intelligently parse the exe structures instead of treating it as a binary stream. Doable, but not soon.

[Michael Bulgrien]

Thanks for you thorough thoughts on this, Craig. I understand the crunch you guys are under...and the "not soon" is completely understandable. Even after BC3 is officially released, what I'd really like to see the most is an OLE property compare. Intelligent parsing of exe structures can stay toward the bottom of the wish list.