Differences between DOpus and Explorer

I am trying to understand a couple of differences in behaviour between DOpus and Explorer.

I have downloaded from the Windows 7 Forums, a registry hack which allows the user to take ownership of files or folders. The code is as follows:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\*\shell\runas]

[HKEY_CLASSES_ROOT\*\shell\runas]
@="Take Ownership"
"Icon"="C:\\Windows\\System32\\imageres.dll,-78"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\*\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"

[-HKEY_CLASSES_ROOT\Directory\shell\runas]

[HKEY_CLASSES_ROOT\Directory\shell\runas]
@="Take Ownership"
"Icon"="C:\\Windows\\System32\\imageres.dll,-78"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"

[-HKEY_CLASSES_ROOT\dllfile\shell]

[HKEY_CLASSES_ROOT\dllfile\shell\runas]
@="Take Ownership"
"HasLUAShield"=""
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\dllfile\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"

The effect is to add a Take Ownership option to the context menu which is displayed when you right-click a file or folder. The user is granted ownership when that option is selected.

This works well in both DOpus and Explorer when a folder is selected, but when a file is selected, the Take Ownership is not offered by DOpus, although is it offered by Explorer as shown in the following screen shots:



It is the same file, in the same folder in each case, and I have tried a number of different files all with the same result.

The other curiosity is illustrated by the same screen shots, which is why I have asked my second question in the same post - sorry.

The file I chose to exemplify the first question happens to be called New Button.dcf. This shows clearly in the DOpus screen shot, but Explorer shows it as just New Button. I have checked the Explorer Folder Options and all looks to be OK there, and all other extensions are showing correctly in Explorer. As I hardly ever use Explorer, I'd probably never have found this had it not been for the first problem, which prompted me to try it.

In case it is relevant, Explorer Replacement in DOpus is set as Replace Explorer for all system folders.

I suspect you have Opus configured to hide Windows context menu items. Does it appear if you hold shift?

As an aside, it seems like a reeeeeeeeally bad idea to replace the runas action. Why on earth do they suggest you do that (and break an existing thing which does something unrelated) rather than create a new action? Perhaps I've misunderstood something but that seems like bad advice.

Hmm, actually, the * key doesn't seem to have a runas action by default (at least on Win7) so maybe it's not as bad as I thought. Still seems a very odd choice to me, and the first line of the registry script deletes any existing runas action (so it seems like it's expecting to replace something, not create it).

Edit: Ahh, I guess it's using runas to trick the shell into elevating the command. I guess that's one way to do it...

[quote="leo"]I suspect you have Opus configured to hide Windows context menu items. Does it appear if you hold shift?[/quote]No, Leo...

I've never exercised that option. (You made me uncertain, and I DID check. :slight_smile: )

Re the actual registry code, I have just taken that on trust, after a number of the Windows 7 Forums members reported that it had worked for them.

If you want to create a similar button in Opus, use this:

Function Type: MS-DOS Batch Function
Command:

@admin
takeown /f {filepath|noterm}
icacls {filepath|noterm} /grant administrators:F

Thanks for that, Leo.

I have done it. A much neater solution.

Hi there,

I've gone through this lately, and i wanna add the action via registry to make it available everywhere.
So, why dopus ignores this action (runas) for files and consider it under folders, isn't this a bug?

It seems to work fine on the .bat filetype, for example.

It may not work on the * filetype for files; I haven't tried to be honest. There are things in the registry script at the top that look dangerous to me, like deleting shell keys and replacing the runas verb on various things.

To be honest, the whole thing seems a bad idea to me. The runas verb has a specific meaning (running the object as administrator; not taking ownership of the object), which does not make sense on the * filetype (you can't run all file types, let alone run them as administrator). This is abusing the fact that runas happens to be run elevated to do something unrelated elevated. There are better ways to do that.

Hi Leo,

Regardless of the danger of replacing this action with our own, I'm talking about dopus neglecting the action even if it's legitimate one.

I've tried also under HKCR\AllFilesystemObjects but in vain!

You can use dopusrt to create a command that works from anywhere and elevates the command it runs:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\takeown]
@="Take Ownership"
"Icon"="C:\\Windows\\System32\\imageres.dll,-78"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\*\shell\takeown\command]
@="\"C:\\Program Files\\GPSoftware\\Directory Opus\\dopusrt.exe\" /cmd @admin:cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"

Hi jon,

Nice workaround!
However, I'd like to know the rational behind this behavior, is it by design? or are there any technical difficulties?

It does not make sense to have a runas verb on catch-all filetypes.

You can't run a text file, for example, but the * and AllFilesystemObjects filetypes will match textfiles.

(And on types that do have runas verbs already, like EXEs, your runas verb to take ownership of them would not work as it would be overridden.)

So the registry changes in the root post don't make sense in two different ways. Opus may be inconsistent with Explorer here, but it's a situation that does not make sense, so I don't see the problem or any reason to spend time digging into it deeper. Of course, if it affects something that does make sense, and that someone has a good reason to want, then that's different and we'd want to make things consistent there.

(As an aside, stuff like [-HKEY_CLASSES_ROOT\dllfile\shell] in the original registry script is also worrying. Deleting all the shell commands under the DLL filetype seems like a bad idea, and suggests whoever wrote the script wasn't thinking or didn't know what they were doing. If I ran that script on my machine, I'd have my two Dependency Walker verbs deleted for no reason.)

Ok, makes some sense!

As for the [-HKEY_CLASSES_ROOT\dllfile\shell] removal line, it's of course faulty one, most likely the script writer meant [-HKEY_CLASSES_ROOT\dllfile\shell\runas] like previous ones.

Thanks for your time.