Gain admin rights

[Chris21]

Hi,
it would be nice to have an option to gain Admin rights if needed. By now I have to (re)start XYplorer to achieve this.

Chris

[Filehero]

Bump.

I'm about to start to play around with VM's to evaluate their practical benefits in daily use ("secure" boxes, development etc). In particular I'm interested to find a good balance between sealing and keeping a basic ease of use. One approach will be to associate one host folder to each vm to aggregate vm specific sets of host folders underneath using symlinks.

Since my host account is a standard one w/o admin rights and UAC all the way up (a setup I still consider a godsend, btw) XY runs unelevatedly by default. I'm afraid, having to start an additional elevated instance each time I want to create a symlink will become painful quite soon.

Hence: is it a major deal to add a "ask-for-admin-rights"-dialog each time it is required during an unelevated session?


Cheers,
Filehero

[admin]

Needs research.

[admin]

OK: On-demand-elevation would be possible but would be mean to ...

a) restart the app "as admin" (after saving all settings) = not really cool IMO.
b) or to pack all operations that need elevated privileges into a separates helper exe = also uncool.

So, why don't you simply run XY as admin right away?

[Filehero]

So, why don't you simply run XY as admin right away?

Because XY would exhibit the "wrong" session context with all user-specific paths pointing to the "wrong" targets.


Cheers,
Filehero

PS: Verdammt ist Dortmund gut ....

[Chris21]

Adding an option to restart XYplorer in elevated mode would be sufficient for me.

[Filehero]

Well I thought implementation would be more straight forward. Something like: OS throws some sort of catchable event upon which the famous dialog can be brought up. Naive me. I guess it's a VB6 thing, right?

I also think a) and b) are "uncool" in general. Clueless now - also with regard to my wish.


Cheers,
Filehero

[admin]

"wrong" session context ... hmm good point.

OS throws some sort of catchable event upon which the famous dialog can be brought up: Yes, I hoped to find something about this but no success. (Nothing to do with VB6) Some day I will see it...

[highend]

The windows explorer isn't restarted when it requests admin rights nor does it use a special helper module, right? So there has to be a way to autoelevate a program after confirming the dialog...

[admin]

The windows explorer isn't restarted when it requests admin rights nor does it use a special helper module, right? So there has to be a way to autoelevate a program after confirming the dialog...

Yes, I think so. But how?

[highend]

http://support.microsoft.com/kb/981778

There is even VB code available

[PeterH]

"Then, the original application restarts, running as an elevated administrator. "

Do you want XY to run elevated, or do you want a function (i.e. some piece of work) to be elevated?
For me I generally want XY to run non-elevated, and only if needed for some action I want to be able to allow it. This way I'm generally protected from making some (but destructive!) errors by accident.

[Marco]

For me I generally want XY to run non-elevated, and only if needed for some action I want to be able to allow it. This way I'm generally protected from making some (but destructive!) errors by accident.

Same here.
My current workflow involves starting (upon logon) two instances of XY: one non-elevated and one elevated. The second one is used if and only if the first one hasn't enough rights to perform what's requested. Other than that, the elevated one always resides hidden in the tray.
So far this works, with little caveats, most notably:
- upon logoff I have to pay attention to what XY I close first, else I'll mess with saving settings;
- when I update XY, I have either to close elevated XY or perform update from within elevated XY.

Costs/benefits balance? I guess benefits outweight costs, so far.

[PeterH]

My current workflow involves starting (upon logon) two instances of XY: one non-elevated and one elevated.

Sounds very reasonable.

It's not often that I use XY elevated - so I start it only when needed.
If I often would run both in parallel I for my part would use different .ini files, so both would be independant. But that's just a matter of habbits.

Maybe it would be helpful if we could "route" commands from the non-elevated to the elevated XY - or is this already possible? (Didn't follow that discussions close enough...)

[admin]

http://support.microsoft.com/kb/981778

There is even VB code available

I know this code. It restarts the app elevated. Not what we want. But maybe there is no other way. Hm.