Total Commander

Sorry, if you don't tell me what I misunderstood, I have no idea what I did wrong.

ghisler(Author) wrote: ↑2022-08-24, 06:49 UTC /O does not override the problem that elevated programs cannot receive messages from programs running with normal user rights. This is a Microsoft security measure, and I do not want to bypass it.

Do you understand that in the first post there is not a word about sending messages?
I started talking about them as one of the solutions, because Hacker asked me about it. Accordingly, if this one is not suitable, then the other two remain:

Fla$her wrote: ↑2022-08-14, 07:53 UTC As a last resort, I prefer a window that gives the right to choose to launch a separate instance. Or even ignore the launch as such.

ghisler(Author) wrote: ↑2022-08-24, 10:34 UTCSo the switch is meant to pass parameters to an already running instance (if that exists). Otherwise it works just like without the switch.

But you don't explain why the second instance of the program opens when there is already one running with elevated rights.
There is a clear gradation between /O and /N.

Fla$her wrote: ↑2022-08-24, 17:41 UTC But you don't explain why the second instance of the program opens when there is already one running with elevated rights.
There is a clear gradation between /O and /N.

Exactly. They are opposites. While /N is to force extra instances, /O is to force no extra instances are created.

Help - Command line parameters wrote:

/O	If Total Commander is already running, activate it and pass the path(s) in the command line to that instance (overrides the settings in the configuration dialog to have multiple windows)
/N	Opens in any case a new Total Commander window (overrides the settings in the configuration dialog to allow only one copy of Total Commander at a time)

(Help text is outdated btw)

To have /O force an extra instance is like having a Close button to open a dialog, or a Cancel button to confirm your choices.

I don't understand why some of you will not accept that there is a difference
using /O if TC instances should running with different privs.
It doesn't matter if the help text is detailed enough or even misleading.
This can be corrected but following the original request would still be a security violation.
For me Christian clearly explained this.

Fla$her wrote: ↑2022-08-24, 17:41 UTC Do you understand that in the first post there is not a word about sending messages?

Do you know that it's really possible? You can send search results from a listbox of a separate search (Alt+Shift+F7) to any TC instance you want.
viewtopic.php?p=417167&hilit=feed+listbox+instance#p417167
Try to do it from an elevated TC instance to a normal TC instance and vice versa.

white wrote: ↑2022-08-24, 20:04 UTC (Help text is outdated btw)

Confirmed. Words "configuration dialog" are still linked to "Configuration - Display" rather than to "Configuration - Operation".

Usher wrote: ↑2022-08-24, 20:35 UTC

white wrote: ↑2022-08-24, 20:04 UTC (Help text is outdated btw)

Confirmed. Words "configuration dialog" are still linked to "Configuration - Display" rather than to "Configuration - Operation".

And it says "allow only one copy of Total Commander" while in TC version 7.55 the meaning of the option changed allowing 1 copy per user.

HISTORY.TXT wrote:31.01.10 Added: Wincmd.ini [Configuration] OnlyOnce now supports values >1 and <-1 to limit the number of copies to x (>0 means per user, <0 means per system)
31.01.10 Added: Wincmd.ini [Configuration] OnlyOnce=-1 allows one copy for TC for all users as in previous TC versions
31.01.10 Added: Wincmd.ini [Configuration] OnlyOnce=1 now allows one copy of TC per user (e.g. when started via RunAs), not one copy for all users as in older versions

In TC 7.50a with OnlyOnce=1, parameter /O does not create an extra instance when there is an elevated TC running.
In the next version TC 7.55 with OnlyOnce=-1 (which should be the same as OnlyOnce=1 in the previous version). parameter /O does create an extra instance when there is an elevated TC running.

Horst.Epp wrote: ↑2022-08-24, 20:20 UTC This can be corrected but following the original request would still be a security violation.

Disabling the opening of the second instance, in your opinion, is a security violation? Serious?
Then why does it already have this "violation" with Onlyone=-1 without /O? Where is the logic?

Usher wrote: ↑2022-08-24, 20:24 UTCDo you know that it's really possible?

Good. You can specify /S= in addition to /N. Not the point.

2white
Thanks for the finds. And what conclusion can be drawn?

Fla$her wrote: ↑2022-08-25, 07:19 UTC 2white
Thanks for the finds. And what conclusion can be drawn?

That prior to version 7.55 the behavior was as you and I expect. /O never forced a new instance when it wouldn't without the parameter. But the behavior changed in version 7.55 and it is unclear whether this was intentional or an unforeseen side effect.

white wrote: ↑2022-08-25, 07:55 UTCand it is unclear whether this was intentional or an unforeseen side effect.

It would be better if this was a side effect that should be fixed with the next release.

I have made a little behaviour table to show which mode does what:

OnlyOnce=1:
No parameters:
1 admin, 1 no admin
1 no admin, 0 admin
Parameter /O:
1 admin, 1 no admin
1 no admin, 0 admin

OnlyOnce=-1:
No params:
1 admin, 0 no admin
1 no admin, 0 admin
Parameter /O:
1 admin, 1 no admin
1 no admin, 0 admin

So /O behaves like OnlyOnce=1. The only difference is this:
Parameter /O:
1 admin, 1 no admin

So when there is already a TC running with elevated rights, /O (and OnlyOnce=1) still allow the creation of a non-elevated TC. Why? The main purpose of /O is to pass new paths to an already running copy of TC. But since the already running TC is running with admin rights, it is protected by Windows from receiving messages from apps with less rights. But the user does want to open these new directories! So the logical consequence is to open a new copy of TC with these paths.

ghisler(Author) wrote: ↑2022-08-25, 08:32 UTCBut the user does want to open these new directories! So the logical consequence is to open a new copy of TC with these paths.

No. The first post describes the situation when the program does this when drive connecting, and not the user himself. And it is completely unprofitable and harmful for the user to run a second instance for the reasons described earlier. Accordingly, there is an important need to save one instance. Opening a directory at any cost is not a priority over preserving instance uniqueness.
Therefore, please make that the second instance is strictly not opened with the /O parameter. For example, by adding the parameter: /O:N

A new parameter would be the best solution for this case. I don't want to modify the /O parameter, which just overrides OnlyOnce (as if it was set to 1). Maybe I could use /O:numeric_value so the user can directly choose the OnlyOnce override value.

ghisler(Author) wrote: ↑2022-08-25, 08:32 UTC So the logical consequence is to open a new copy of TC with these paths.

But then it no longer does it's main purpose, but does the same as passing new paths with no /O parameter and should behave the same way. Otherwise it would act like the /N parameter in this situation and that's contrary to its purpose.

Fla$her wrote: ↑2022-08-25, 08:49 UTC Therefore, please make that the second instance is strictly not opened with the /O parameter. For example, by adding the parameter: /O:N

Or make it that /O doesn't force an extra instance in this situation except when the parameter /N is also used.

ghisler(Author) wrote: ↑2022-08-25, 09:10 UTC A new parameter would be the best solution for this case. I don't want to modify the /O parameter, which just overrides OnlyOnce (as if it was set to 1).

ОК, you can add a new one. Or you can add an Onlyonce value that will not be overridden.

ghisler(Author) wrote: ↑2022-08-25, 09:10 UTCMaybe I could use /O:numeric_value so the user can directly choose the OnlyOnce override value.

Do you mean override factor itself? Yes/No (1/0) ?