Binary compare of archives from the context menu

[obetz]

Hi Scooter Software,

although I found several old requests, I didn't find a solution:

How can I get BC telling me that two ZIP files are binary equal instead of opening them as folders if I compare them by the Explorer context menu?

IOW I mark two ZIP files and select "Compare" from the context menu. I want to know whether they are binary equal, but BC only shows me the contents.

[Aaron]

Hello,

Unfortunately, we do not have a method to treat archives as files only from the context menu. You can disable archive support for a specific extension from the Tools menu -> Options dialog, Archive Types tab, select zip and delete *.zip; text from the extension list, then restart BC4. This would then always treat them as files, and never as archives, in the shell extension or within a Folder Compare. Adding support to treat them as files or folders from the shell extension is something on our wishlist.

[obetz]

Since other files are also checked for "binary identical" when compared from the context menu before opening the specific comparison: Why isn't this done also for archives?

Please implement this, I'm not the only one requesting this.

It is a lot of work the check whether the two archives are identical

[Aaron]

Archives are considered Folders for the shell extension if the archive type is defined, so their contents are opened (and can be scanned as Binary).
If the definition is removed, then archives are files, and are treated as files from the shell extension (scanning the archive file itself). You can pick one strategy or the other, but can't flip between them on the fly.

It's on our wishlist to add an enhancement to our shell extension to allow archives to be treated as Files or Folders on the fly from the shell extension, but that is not available in the current version.

[obetz]

Hello,

My suggestion was to silently do the binary comparison first - like it is done for other files.

If the two archives are identical, show this information - as it is done currently for other files. Then ask whether to open.

If they are not identical, open the directory comparison immediately.

IMO this is not a "big new feature" but just about making the behavior consistent.

[tfrost]

In my view that would be an unnecessary complication. My zip files are usually big, and binary compares would slow things down. More importantly, if the ZIP files are of a similar or identical set of files (and why else would you want to compare them in BC) then I cannot recall ever seeing files with different content which have an identical byte count, so the binary compare is surely redundant.

[Aaron]

There are scenarios where it would be beneficial, but changes to the Windows Shell extension logic are not trivial. It currently only supports the concept of Files or Folders, and it has to be a solution that can determine a (configurable list of supported) archives before executing BC4, since BC4 itself is not called to until after selecting the shell extension command. It's something that's been on our radar to tackle, but we've have a few other larger projects already scheduled and limited resources.

[hypno]

My work-around for this has always been to simply change the zip filename(s) to some arbitrary extension. For example, "somefile.zip" becomes "somefile.zip.temprename". Then the context menu will allow a binary compare. This has the advantage that I don't need to remember which BeyondCompare setting to change and I don't need to worry about forgetting to change it back. If I'm worried about forgetting to rename the file back to its original name, I pick a really long file name that makes it clear I've renamed it. The long filename makes the file stand out in any sort of file listing. If I happen to forget the rename, this increases the odds I'll notice it in the future and provides enough context that I can make a correction.

This BC limitation has been a frustration for me for many years but I'm somewhat familiar with shell extensions and realize it isn't really feasible to change the behavior. The limitation seems due to Microsoft's design and is beyond ScooterSoftware's control. Perhaps they could add code to do it, but I suspect even the "best" solution would be a serious kludge. I also suspect it would cause sluggish response times for every context menu the shell generates, assuming it could even be done.