Compare Contents

[Michael Bulgrien]

Correct me if I am wrong...but this feels like a bug:

• "Automatically scan subfolders in background" is disabled
• "Folder compare is opened, sub-folders are not expanded
• "Right-click on a selection of one or more subfolders and choose "Compare Contents..."
• Blinking X starts in toolbar
• Cancel "Compare Contents" dialog
• Blinking X continues
• Eventually the color of the opposing folders change to reflect content differences

If auto scan is disabled:

1. Why does compare start before user selects an option in the "Compare Contents" dialog.
2. What method of compare is being used since dialog did not wait for user to select one?
3. Why does the compare continue when the user cancels the dialog?

[Zoë]

If I had to guess, I'd say you have some sort of background content comparison on, in which case this is somewhat intentional behavior.

1) The folders start building as soon as the dialog appear in order to show the file counts and sizes on the left and right of the "Selection" groupbox.
2) Whatever method you have configured in session settings.
3) If you have background content comparisons enabled Cirrus will automatically start them whenever you visit a folder, either interactively, through "Automatically scan subfolders in background", or by performing a file operation. In this case it doesn't care whether the file operation you started is "Compare Contents" or "Copy to Other Side". It keeps going after you cancel out of the dialog because that cancels the file operation you were going to start, not the automatic background process that was triggered by the folders being built. If it was in the middle of building folders when you canceled it wouldn't have continued to visit unbuilt subfolders though.

[Michael Bulgrien]

If I had to guess, I'd say you have some sort of background content comparison on

You seem to have ignored my first bullet. The "Automatically scan subfolders in background" option is disabled/turn off. What do you mean by "you have some sort of background content comparison on"? Are there settings I don't know about that are causing this behavior? Is so, please explain.

P.S. The background scan does not begin until I launch the Compare Contents dialog, and it only occurs on the folder(s) that are selected when the Compare Contents dialog opens. If I don't open the dialog, the background scan never occurs.

[Zoë]

Session->Session Settings->Comparison->Compare contents:->CRC/Binary/Rules-Based

[Michael Bulgrien]

I don't understand. If "Automatically scan subfolders in background" is disabled, then a background scan should NEVER occur on an unopened folder unless the user opens the folder or performs a function against the folder.

Opening the "Compare Contents" dialog is not (or rather, should not be considered to be) a performed operation against the folder(s) until the user completes the dialog by clicking the Start button.

What good is a Cancel button to prevent the Content Compare if the user is not given a chance to use it before a compare begins?

What good is a list of comparison modes to choose from if Cirrus has started with a default mode already?

Please prevent a background compare from being triggered by the "Compare Contents" dialog until the user selects a compare method and clicks Start.

[Aaron]

Summary of Options

Alright, let me try to explain this. If you have any questions, please let me know. I will also provide a brief summary, for anyone hopping in and just reading this issue:

The issue is if you right click and select Content Compare, there is a mini-preview in that Window that we need to process/build in order to get that information. When we process any folders that have not had a Content Compare run against them, but the Session has a default Content Compare, we then run the Content Compare.

Having a "default background content comparison on" means you have a checkbox in Content Compare in the Session's settings and selecting either Rules, CRC, or Binary as the type. If you wanted to, you could uncheck this box (or set it to Size Only), and only run content comparisons manually. We are looking into redesigning this dialog to make this process more intuitive and expanded.



Summary of Issue:

If you open a Session, and click the referee, you are greeted with the option to set a default comparison in the Comparison Tab. This default comparison is triggered at a point where the program 'does' something to the folder. Once we visit a folder, or perform some action on it, we've already invested an amount of resources to get this far, and performing the Compare Contents is such a common action (we are a comparison software) that we then use this opportunity to run the Comparison.

Perhaps getting the directory structure itself takes several seconds, and they only need to compare a specific part, rather than the whole thing. For this we have the option under the Handling tab "Automatically scan subfolders in background". This option is also on by default, since most of the time it is ok to run background comparisons. If the user visits a folder specifically, then we'll process that one in the foreground in order to show it quicker. In this slow ftp case, however, we can turn this option off, so we don't waste any transfer rate or resources calculating things in the background we don't directly visit.

So with Content Comparison set to On, but Automatically Scan Subfolders set to Off, we will still automatically scan any folder we interact with, but not any folders we do not.

[Michael Bulgrien]

As I've repeatedly emphasized: Having "Automatically scan subfolders in background" disabled leads the user to believe that a subfolder scan will not occur in the background unless it is absolutely necessary.

Opening a dialog whose sole purpose is to choose a specific type of content comparison is NOT a scenario that requires a background content comparison to be done automatically! IT SIMPLY DOES NOT MAKE SENSE!

How difficult could it be to pass an override parameter to the scan routine to bypass the default background content compare if the scan was initiated from the Content Comparison dialog? (And yes, I am aware that this same bug exists in BC2.)

Having a "default background content comparison on" means you have a checkbox in Content Compare in the Session's settings and selecting either Rules, CRC, or Binary as the type.

This is a poor design then. Having a default background content comparison mode spcified/configured/selected (whatever you want to call it) should not automatically mean that the feature is "ON" where it does not make sense to be on. One should not have to change their default configuration of choice simply to run a manual background scan, then have to change it back again when they are done.

The issue is if you right click and select Content Compare, there is a mini-preview in that Window that we need to process/build in order to get that information.

The Content Compare dialog shows the following stats:

• Number of Files
• Number of Folders
• Size on Disk

A content compare is NOT required to gather these stats! In fact, a content compare will only slow down the process of populating this information and returning it to the user. When I initiate the Content Compare dialog against two remote machines, I get the following dialog:



In this case, I waited for more than 5 minutes, and the stats on the left side of the dialog NEVER DID UPDATE! These stats should be returned right away...not delayed by a content scan that was initiated in the background.

By the way, the left hand side should have shown:

• 26 file(s)
• 8 folder(s)
• 54.2 MB

[Zoë]

Michael,

Pardon me for being blunt, but if BC is already doing a background content comparison and you tell it to also do a foreground comparison you're probably doing something wrong.

The background content comparison runs automatically whenever a folder is visited or a file is changed. That's it's entire reason for being. If you don't want it to do that why are you turning it on?

I do think that there are rare circumstances where doing both can help, but between your post and some internal discussions I now think the confusion and complications outweigh those cases. The "Compare Contents" action isn't as necessary as it was in BC2, so I think the way to simplify things is to just not offer it if background content comparisons are active.

[Michael Bulgrien]

Wow, this is really frustrating. We don't usually have such a difficult time communicating. Your questions clearly indicate that you do not understand what I am describing, or you would not be asking these questions. I must not be communicating clearly enough. Please bear with me as I answer your questions and try again.

If BC is already doing a background content comparison and you tell it to also do a foreground comparison you're probably doing something wrong.

Cirrus is NOT already doing a background content comparison.
I have "Automatically scan subfolders in background" disabled.

The background content comparison begins the moment I launch the Compare Contents dialog from the context menu...but before I have a chance to accept or override my default compare settings and click on the "Start" button.

Further explanation: I disabled/unchecked the "Automatically scan subfolders in background" option because I often work with large remote folder trees for which a background content scan of the entire tree saps my system resources for long periods of time. There is no reason to perform an automatic background scan on the entire tree structure of the base folder if I am only going to be working with a subset of its subfolders (and their subtrees).

The background content comparison runs automatically whenever a folder is visited or a file is changed. That's it's entire reason for being. If you don't want it to do that why are you turning it on?

The folder has NOT been visited. It remains collapsed (was never expanded).
The contents of the folder have NOT changed. No activity has been manually initiated against the folder.

By your own definition, the reason for the automatic execution of a background content comparison has not been met.

According to industry standards, the "..." at the end of a menu option indicates that a dialog will be launched from which the specified menu option can be executed or completed. For example:

Right-clicking a folder pair and Choosing "Rename..." does not start a background scan. It opens a dialog.
Right-clicking a folder pair and Choosing "Attributes..." does not start a background scan. It opens a dialog.
Right-clicking a folder pair and Choosing "Touch..." does not start a background scan. It opens a dialog.

However:

Right-clicking a folder pair and Choosing "Delete..." does start a content compare when it opens the dialog.
Right-clicking a folder pair and Choosing "Compare Contents..." does start a content compare when it opens the dialog.

These last two are the exceptions. From a purely technical perspective, I understand that Cirrus has scanned the folders in order to perform a file and folder count...but, from the user's perspective, no activity has been initiated. I have not accessed the folder or changed it's contents because I have not yet completed the dialog to execute the functionality behind the menu option. If I choose to Cancel the "Delete" option or to Cancel the the "Compare Contents" option then, from the user's perspective, the state of my folder session should not have changed because I did not initiate any activity against the selected folder pair.

I do think that there are rare circumstances where doing both can help

Wanting to override the default compare settings for a specific subfolder is not a rare circumstance. It is a perfectly normal and potentially frequent activity.

between your post and some internal discussions I now think the confusion and complications outweigh those cases.

The confusion comes from Cirrus triggering a background compare when the user has not performed any activity against the folder or its contents. Period. It is that simple. All you need to do is prevent the background compare from executing when the dialog is opened and the confusion is gone.

I think the way to simplify things is to just not offer it if background content comparisons are active.

That will in no way simplify things.

If you disable the "Compare Contents" menu option when a user has a default compare method defined, then there will be no way for a user to manually initiate a compare of the contents of a collapsed folder pair other than to open it.

If you disable the ability to specify a default compare method when the user has the "Automatically scan subfolders in background" option unchecked, then there is no way for the user to have folder content compared when a folder is opened or its content changed without forcing the user to always have to endure or cancel automatic scans of huge collapsed folder trees.

And, likewise, if you disable the ability to uncheck the "Automatically scan subfolders in background" option when a user has a default compare method defined, then there is no way for the user to prevent unwanted resource intensive background compares from happening automatically on folders that have not been touched, and yet have touched folders and files compared automatically with a default compare method.

I don't understand why you keep complicating this issue unecessarily. Simply launching a dialog should not trigger activity that effects a visual change to the User Interface unless the user completes the dialog. That is application development 101. Just because a file/folder count has been made for the dialog doesn't mean that the content of the folder pair should be compared and the colors of the folder pair updated to reflect the results.

[Tim]

Sorry for all the confusion. I hope this helps:

A "scan" is not synonymous with background content comparison. A scan visits folders recursively, building out our comparison tree structure. The "Automatically scan subfolders in background" option merely causes folders to be visited automatically when a session is loaded.

When you define content comparison in the comparison criteria, a background content comparison is queued whenever a folder is first visited. This is a low-level side effect of visiting a folder, whether it’s during a scan or when the user opens a folder.

To answer your questions:

1. Why does compare start before user selects an option in the "Compare Contents" dialog.

Because the folders were scanned in preparation for the explicit Compare Contents command, and your comparison criteria have instructed BC to do a content comparison whenever folders are visited.

2. What method of compare is being used since dialog did not wait for user to select one?

The method which you defined in the folder comparison’s rules dialog.

3. Why does the compare continue when the user cancels the dialog?

Because you cancelled the explicit Compare Contents command but not the background content comparison.

Clearly, you are using features available to you and the resulting behavior is confusing. I agree with you on that. We are studying the whole comparison criteria environment and have some ideas on how to clarify actions and enhance performance. Please give us some time to develop these ideas – I expect we’ll have some improvement in the next release or two.

[Michael Bulgrien]

This problem is still occurring (both with a right-click Compare Contents from the context menu, and from a Compare Contents triggered from the toolbar).

Quoting industry standards:

If a command requires additional information to complete its intended action, and you use a dialog box to supply that information, follow the command with an ellipsis (...). The ellipsis provides a visual cue that the command requires additional information.

Label a button Cancel if canceling returns the environment to its previous state (leaving no side effect)

Since a content compare starts without the "Compare Contents" dialog returning additional information, the "ellipsis" is improperly used.

And since cancelling the dialog does not leave the environment in its previous state, the "Cancel" button is improperly used.

Please do not start the compare until the user clicks "Start"

[Tim]

Michael,

There are two compare contents functions: The automatic background content comparison that you can configure in rules, and the explicit Compare Contents command.

What the Compare Contents command does or doesn't do is not the issue. Any command's preflight phase will invoke the background content comparison if it affects un-scanned folders. You could just as well complain that the Copy command, when canceled, continues to compare contents in the background.

If you don't want things to run in the background, independent of whether or not a foreground command has ellipses or is canceled, then please don't configure BC to do so.

Here's what I'd like to do to improve the situation and reduce confusion:

1. Remove the Compare Contents command
2. Add a Scan command (without ellipses or a dialog) for un-scanned folders

[Michael Bulgrien]

Any command's preflight phase will invoke the background content comparison if it affects un-scanned folders.

That is precisely my point. It shouldn't when no activity has been initiated. The dialog box is not an issued command. A user can cancel the dialog. Clicking the "Start" button is the issued command. That is where the "preflight phase" should kick in.

If you don't want things to run in the background, independent of whether or not a foreground command has ellipses or is canceled, then please don't configure BC to do so.

Tim, I am comparing files that require content checking. It would not make sense to disable it. I just don't want Cirrus initiating things in the background before I've instructed it to do any activity.

Here's what I'd like to do to improve the situation and reduce confusion:

1. Remove the Compare Contents command
2. Add a Scan command (without ellipses or a dialog) for un-scanned folders

Why would you remove a dialog that allows a user to over-ride their content compare settings? Getting rid of something good in order to remove unnecessary confusion is a poor reason to do so. Just delay the "preflight scan" until after the user initiates the activity.

[Tim]

Just delay the "preflight scan" until after the user initiates the activity.

Then it wouldn't be a preflight, would it? The scan of unprocessed folders identifies exactly what will be acted upon by the command, before the user commits to it. It allows is to display the file/folder counts in the operation dialog.

[Michael Bulgrien]

I've suggested it before. Provide a toolbar button that lets a user toggle (temporarily disable) background content compares without modifying the default session settings, and that I'll be a happy camper.
This is what it might look like behind the scenes (in Session Settings):



Whether it is a single checkbox or two option buttons doesn't really matter.
What matters is being able to disable content compares without losing the configuration.