Despite both ZIP options being disabled, every time I run Directory Opus, it recreates the context/drag handlers for ZIP.
I've searched the forum for solutions and I found one post claiming that someone didn't remove the default handler. To be certain, I re-enabled and re-disabled -- that didn't help either.
Are you seeing the menu items when you right-click files, or is the issue just on the registry side of things?
There's Enable Archive context menu (Preferences / Zip & Other Archives / Archive Context Menu) which should let you turn off all the menu items, whether or not Opus is the default Zip handler.
Zip isn't the only archive type Opus handles, so the menu could be appearing for a different type even if Zip is turned off.
I should have mentioned that I have the Archive Context Menu > Enable Archive context menu -- disabled (unchecked)
The issue is only on the registry side of things. It's a very long story but it causes some strange behaviors in Win Server 2022 vNext (aka 2023/2024).
Here's a quick summary from MS AutoRuns (registry key in purple):
With all of the ZIP/context menu options disabled in Directory Opus, then removing all of those Context hooks -- Directory Opus will reinstall them on the very next run, every time.
Is there another setting that will help override this?
To clarify:
I see absolutely no problem at all with the handler being installed ... once.
The problem is that no program should be so obtrusive to re-install a shell hook when it's explicitly been deleted. If doing something obtrusive like re-embedding at several shell points, there should always be a setting (advanced/hidden if required) to disable.
From Google to Microsoft to Apple (the absolute worst and most obtrusive offenders), none of them will re-install shell handlers, particularly when I'm not choosing to use them. There is a reason that even the most egregious offenders don't force re-install features not being used that have explicitly been deleted.
You asked about the issue --
This is a development system and without going into the very nuanced details, I'm not in a position to set policy for the machine. I paid extra to purchase a portable license to be allowed to use Directory Opus portably -- and yet it doesn't operate portably -- at all. It appears the only option would be to run DOpus from a USB drive, which also isn't allowed in this case. I assumed that by purchasing the USB/U3 Export license addition, it would solve this issue; however, it appears this is not the case.
Please allow an advanced setting or some other way to not re-install handlers. If nothing else, at least for people that buy the portable version, regardless of whether it's run from USB or fixed-HDD.
That's not really true, in my experience. A lot of things will self-repair and almost all of them will put things back in the registry when an update is installed.
There's no way for software to know why registry entries are missing, and if something was deleted by other software in error or deleted on purpose.
If you want to disable the handler, a tool like ShellExView can do that without deleting the registry values. It adds a flag on them to say they are disabled, which File Explorer (and Opus) check before loading an extension. That's the proper way to disable a shell extension system-wide.
(I think AutoRuns may work differently, in a worse way: It moves the registry details into a dummy place, which just means they get re-created the next time you update the thing that installed them. ShellExView works better.)
A portable install of Opus should not modify the registry at all. It doesn't have to run from a USB drive (you can copy the files to an internal drive), but the USB drive Opus was exported to has to be present.
A portable install of Opus shouldn't install the shell extensions. If they're installed it sounds like you're running a normal install of Opus not a portable one. (Or there's a bug in the portable version. I can look into it you're seeing the registry entries with a portable install.)
