Could you please update TC code for cm_EditOwnerInfo?

[brahman]

Hello,

when I run cm_EditOwnerInfo on a file, I get the following message:

"Windows cannot take ownership as requested because a component of the software you are using that is required to perform that function is not compatible with any version of Windows released after Windows Server 2003. Contact your software vendor to find out if this software has been updated for current versions of Windows."

Could you please update this software component in the next TC version?

[Horst.Epp]

Search for cm_EditOwnerInfo and you will find that this will not happen

[ghisler(Author)]

Just press Alt+Enter, then open the "Security" tab and click on the "Extended" button. There is an option to take ownership.

[Raart]

Five years are gone and e.g. this bug hasn't been solved. The workaround playing piano with the keyboard isn't acceptable and Win 10 and Win 11 refuse to agree with it anyway.
I'm testing your willingness to accomodate in a serious manner bugs in Total Commander in a reasonable time. If you think to have no time for this task, open source TC.
As you can verify I paid for TC as I'm of the idea your efforts to write it deserve at least some economic contribution. In addition I'm ready to help to debug it in a collaborative manner, noticing you each glitch I'll find (and I have a list of).
TC is a wide project and I'm aware that it takes much effort to work and update it. Nevertheless I expect debugging will be made in time.
The cm_EditOwnerInfo issue is an example only, under more exisiting, so don't yammer (auf gut Deutsch) this writing is unmotivated and restricted to this particular case.

Have a nice day

Andreas Troschka.

[Sir_SiLvA]

In addition I'm ready to help to debug it in a collaborative manner, noticing you each glitch I'll find (and I have a list of).

If that is true you should post them in the bug forum

[ghisler(Author)]

Microsoft has removed the function, so there is nothing I can do, sorry.

[AntonyD]

so there is nothing I can do

1) To remove from the code unsupported commands at least? As I see cm_EditOwnerInfo+cm_EditAuditInfo+cm_EditPermissionInfo
these already THREE functions do not work at all. We can see the same error window after execution each of them.
2) To introduce the support of 3rd party utilities|tools|scripts|..?..| - which we can "to google" in the Internet, and which CAN do
the requested abilities... But obviously that we should do that - such abilities should be prebuilt inside the TC's code...

[Sir_SiLvA]

1) To remove from the code unsupported commands at least?

No backwardscompatibility

[petermad]

backwardscompatibility

Exactly - I still use that feature when using Windows XP, which does not support this through the context menu as later Windows' does.

The same applies to cm_EditPermissionInfo and cm_EditAuditInfo

[JOUBE]

2) To introduce the support of 3rd party utilities|tools|scripts|..?..|

? This is the specialty of the TC and is already available in countless variants in the TC...

[AntonyD]

backward compatibility may well be hidden under conditional compilation directives.
And when calling these non-working menu items, then it is worth displaying a MORE accurate description of the problem:
that in the current specific version of windows 7|8|10|11 - this functionality is completely inoperative and to resolve
issues related to this command, you should go to the Internet.
Because the current text of the message gives absolutely no reason to doubt that it is simple "another mistake" by Total
itself, it’s just said in a veiled way.

countless variants

do exist only in a "spherical vacuum". The user should do exactly as I indicated - go to the Internet and look for solutions
to the issues only there. Not in a Total itself.
But it would be entirely possible to choose at least one third-party solution and implement it by default in Total.
So that this'll be exactly the solution, at least to a first approximation. Instead of leaving the situation as it is now:
It simply displays a message text about some error/problem - somewhere in Windows or somewhere else....

[Sir_SiLvA]

backward compatibility may well be hidden under conditional compilation directives.

I doubt that is possible with Delphi 2 (apart from that its imho not needed)

2nd the error msg is from WINDOWS not TC so your complain has to be directed to microsoft

implement it by default in Total.

No external software should EVER be implemented by DEFAULT security risk

[AntonyD]

2nd the error msg is from WINDOWS not TC so your complain has to be directed to microsoft

The source of this text window is not important. The text does not provide correct, up-to-date and truthful information - which means it should be suspended and instead of this window, a window from Total should appear with a more correct message, as I wrote above.

No external software should EVER be implemented by DEFAULT

By default, we already have a lot of third-party code running in Total, especially in unpacking.
No one is saying that the third-party tool of choice to solve this problem should be a proprietary and closed/packed some.exe file.
It is quite possible to replace all the actions hidden in the now non-working code of these three commands with scripts that can be
simply placed next to the main totalcmd.exe

The main thing is that the user should not be forced to SEARCH for a replacement for what seems to be declared as working code,
but in fact it has not been working for a long time. windows 7/8/10/11 - isn't it enough already?
In the end, WHERE do these commands work? Only in XP and earlier versions of Windows?
Aren't we playing around with legacy platform support for too LONG from a security standpoint?

[Sir_SiLvA]

2nd the error msg is from WINDOWS not TC so your complain has to be directed to microsoft

The source of this text window is not important. The text does not provide correct, up-to-date and truthful information - which means it should be suspended and instead of this window, a window from Total should appear with a more correct message, as I wrote above.

Ofc the SOURCE is important. And that source is Windows, that the error description is typical microsoft nonsense is not tcs fault.
So, as I said before this is not possible nor needed => Backwardcompatibility

Aren't we playing around with legacy platform support for too LONG from a security standpoint?

If you dont like it you can always use one of the worse alternatives to tc that are out there
TC has always primed itself for beeing BACKWARDCOMPATIBLE.
(even to the point where it gets silly like the default ini still being called Wincmd.ini, after over 21 years as TC )

The main thing is that the user should not be forced to SEARCH for a replacement for what seems to be declared as working code,
but in fact it has not been working for a long time. windows 7/8/10/11 - isn't it enough already?

The TC code is working fine. Its Windows that was changed -> complain to microsoft

[AntonyD]

2Sir_SiLvA
You are answering only from the point of view of a developer or a person who very, very understands the inner kitchen of development..
It's not good or bad - it's just your decision. BUT! it is very highly specialized.
Go down to earth - where ordinary users of the final product live. Even here on this forum, I was not immediately able to find at least
some additional data on these three non-working commands. Do you really think that the majority of ordinary users will be more
meticulous in their search for the truth?
When does a simple user see text in the window that is completely incomprehensible and does not correspond to the actions performed
after calling the command in Total - of course, he/she considers this window as part of the Total code. Those: weird text = weird Total.

Therefore, I propose to make a REAL clarification - do not execute these commands in those versions of Windows in which they do not work.
And for some reason there are already an overwhelming majority of them! Those literally the number of versions of Windows where the code does not work is twice as many as the number where it works. And what is the point of this “much needed backward compatibility”?

The TC code is working fine. Its Windows that was changed -> complain to microsoft

Why should I suddenly complain? Why did they remove the insecure code? So in Total, you just had to DELETE the legacy code in the same way.
Total shouldn't even try to do something that doesn't already have code support from Microsoft.