bug? Folders stay yellow

[JustMe]

BC3 3.0.8 (build 9206). Windows (2000 and XP). Comparing the same local directory (c:\documents and settings) on the left and right so that everything is identical.

Even when session->session settings->handling->automatically scan subfolders ... is checked the display shows folders in yellow with no size field. The only way to see the folder colors is to also check expand subfolders ...

The help indicates that the reason to automatically scan subfolders is so they can be colored correctly before they are opened, so isn't it odd that they stay yellow until expanded?

[Michael Bulgrien]

Unexpanded folders color for me. BC3 does not simply color each side as equal when the folder names in the MRU dropdowns are identical...it still recurses through the subfolders on both sides and performs a compare. If you have a blinking red dot on the toolbar (with a white X through it), it means the compare is still taking place and each folder will be colored when the compare of that folder pair completes.

[JustMe]

Thanks for the reply but I waited until everything completed before I posted the original comments. I'd attach a .bmp showing the result but I can't get it small enough to satisfy your conditions and still be useful.

Turn off the "expand folders" in the session settings->handling tab. I can reproduce this with 3.0.9 (build 92222) 100% on three different windows machines (2000, XP Pro, and 64-bit XP-Pro) and two SuSe Linux boxes. Until a folder is expanded it remains yellow and does not display size information. Expanding a folder by hand causes the folder to turn gray and display size information. Performing a full refresh at that point 1) closes the folder, 2) colors it yellow 3) continues to display the size information.

The key is to disable the setting: sessions->session settings->handling->expand subfolders when loading session.

[JustMe]

This may be related to another post: http://www.scootersoftware.com/vbull...ead.php?t=3737

[Zoë]

This is intended behavior, though I can see arguing against it in certain cases.

In BC2 if the base folders were the same paths then it didn't build any of the folders because it knew they would all match. Top-level orphan folders also weren't built because it knew they were all orphans, which also occurred in the case where you only had one base folder filled in. It would filter them correctly, but still display them as yellow until they were built. I think this was internally consistent and I like the way it worked.

In BC3 we added the "Build top-level orphans" option, but I wasn't thinking of these interactions when I added it. To make the behavior consistent again that option would probably have change so it affects both cases and would have to be named "Build folders whose comparison results are already known" or something equally convoluted.

BC3 does have a bug in that it doesn't filter the unbuilt folders as exact matches, which it should.

If you're just using BC to see the cumulative sizes of a folder's contents, you should also consider Folder Size or TreeSize Free.

[chrroe]

Hi!

There is another workaround for making BC3 calculate the cumulative sizes of a folder's contents (which I use quite often):

• Open only one folder in a folder compare (leave the right pane empty).
• Select the folders you are interested in with left mouse-button.
• Now right-click and choose "Compare contents..." from the context-menu.
• In the appearing dialogbox wait until the "Scanning folders" process has finished simply press "Start" or "Cancel".

Although this "compare" makes no sense at all, you get the calculated folder-sizes as a result in the right pane.

Bye
Christoph

[JustMe]

OK, I can accept your explanation.

I wasn't actually depending on the comparison for anything. I just noticed that things which, in my mind, should obviously be gray remained yellow.

Thanks for the follow up. You guys are really good at watching the forums and responding.

[Lutz]

Need to scan subfolders in background

Hi,

first I would like BC3 to scan subfolders in background if this checkbox is checked even if the folders are orphans or the same on both sides (btw: compare contents command is not active with the same folder on each side).

My use case for this behaviour is that I use Alignment overrides (e. g. *.dat=*.txt) which are not respected by the initial decision if the folders have to be scanned, I think. In my case there appear different files with the same base folder on both sides.

The result I get with this Alignment override is, that I see binary logs on the left side ordered by creation time, aligned with the files converted to readable format (conversion time doesn't matter) and binary logs that weren't converted yet (*.dat on both sides). A binary log and its converted file stay in the same path.

Greetings Lutz

[JustMe]

No way to force the compare.

Lutz makes a good case. I mentioned the inactive compare contents here, too: http://www.scootersoftware.com/vbull...ead.php?t=4037. I now realize it is probably a side effect of comparing identical folders but Lutz's alignment argument seems valid.