No announcement yet.

minor cab compare bug

  • Filter
  • Time
  • Show
Clear All
new posts

  • minor cab compare bug

    I'm comparing the entire DVD of Visual Studio against the downloaded ISO. There are a bunch of cabs. If you double-click on a cab it will open it up just like a folder. I did this while it was being compared, and while the folder was still open, the comparing logic finished with this cab and declared it identical. Problem is since it was open it now won't go away when I change the view to differences only.

    Notes in the picture: 1 - It should only show differences
    2 - You can see the cab has been declared identical
    3 - The cab icon is still white, as if it wasn't done yet

    Thanks, Eric T.
    Build 446

  • #2
    update -- all's well when compare finished

    Once the compare completed, all the icon colours changed to grey and disappeared when I showed differences only


    • #3

      Glad to hear it was resolved.

      In your earlier screen shot, the white color represents "uknown, scanning" for the comparison result, so that is why it wasn't filtered out when you took the screen shot.

      You can select View|Legend from the menu for a list of all the file and folder colors and their meanings.
      Chris K Scooter Software


      • #4
        Eric's concern has been raised by other beta testers as well. I've noticed the same thing as well in my folder compares. While I understand the technical reasons behind files that remain in a folder view even though they violate the current filter, it is obvious that some users would prefer an option to have Cirrus always drop a item from the list when a re-evaluation of the item determines that the item does not match the current file filter. I believe that this is a reasonable expectation and that it would be a useful enhancement.
        BC v4.0.7 build 19761


        • #5
          I think it would be worth considering an intermediate screen refresh to remove a file pair from the view right away after a user performs a compare of that specific file pair. In other words, compares done in the foreground should have presedence over (and return results sooner) that a potentially long background compare that happens to be running at the same time.

          It may be a poor comparison, but I see this as similar to right-clicking on a missing image in Internet Explorer and choosing "Show Picture" from the context menu to load that particular image right away instead of waiting for Internet Explorer to load all of the earlier missing images before loading the one you're really interested in seeing.
          BC v4.0.7 build 19761