Gain admin rights

[admin]

Ahem, I just made some test under Win7: UAC support works fine as long as you use the shell for copying files! So when working
- under UAC
- as non-admin
- in protected folders (e.g. C:\programs)

>> simply turn off Custom Copy and all problems are gone.

[grindax]

.

[Marco]

Isn't possible to "simulate" a file operation without CC first, to see if UAC will be triggered, and then, if so, sending an elevation request to the OS for XYcopy?

[Filehero]

...for copying files! So when working...

>> simply turn off Custom Copy and all problems are gone.

I would rather say "almost all" since symlink creation isn't affected.


Cheers,
Filehero

[admin]

"so many downsides"? Are you in a bad mood? It's an alternative to shell copy. If you don't like it don't use it. It's optional.

And, as I said, I cannot reproduce your hardware/network configuration here, but in my tests custom copy is always same or faster than shell copy. I use it all the time.

[admin]

Isn't possible to "simulate" a file operation without CC first, to see if UAC will be triggered, and then, if so, sending an elevation request to the OS for XYcopy?

No. You know, I do nothing here. What you see is completely handled by the shell. UAC comes from the shell, so let the shell deal with it.

[grindax]

.

[admin]

Are you in a bad mood? It's an alternative to shell copy. If you don't like it don't use it. It's optional.

I do like the extra functionality and visual feedback it provides, and do wish to use it. All I'm saying is that unfortunately I can't because for whatever reason it takes minutes to do the same thing that the shell does in seconds. And for that reason I have turned off this optional feature. I appreciate that you did already look into this to see if anything could be done.

As it stands you are the only one who ever reported Custom Copy slowness, let alone such a dramatic one. I would love to reproduce it but can't. But you should not carelessly talk about "so many downsides" IMO.

[Filehero]

Hi,

let me first say, if I'm coming over sort of confused - I was! Three days ago, my damn "core" machine decided to boot only every 2nd, 4th, then 3rd time - only topped by refusing to boot at all.
At least, now it seems, the problem is solved (but still not understood...). So here I'm back again.

Question: could the solution/approach described in here be used to address the "needs admin rights"-issue in a rationale way? I know in essence this is the "start new elevated instance"-approach. But if done that way, I really could life with it. Especially since all information I could get officially and from "the underground" end up with the same conclusions, that is - yes, you guess right - "restart your stuff elevated".

So: can we marry the "New /fresh switch"-approach and the "need-admin-rights"-case in a way not changing the current settings of the instance the call originates from? Basically it would be a "disposable" copy instance with elevated access rights.


Cheers,
Filehero

[Marco]

So: can we marry the "New /fresh switch"-approach and the "need-admin-rights"-case in a way not changing the current settings of the instance the call originates from? Basically it would be a "disposable" copy instance with elevated access rights.


Cheers,
Filehero

Keeping in mind that a fresh instance would also be a "bare" instance: no tags, no customized settings, nothing. Maybe a "stealth" clone of the current config would be more useful.

[Filehero]

Maybe a "stealth" clone of ...

This is what I meant with copy instance. Another instance with the same, but read only settings, to be closed right after the elevated stuff is done.

Thanks for the pointer.


Cheers,
Filehero

[admin]

But "read only" would only apply to the saved settings, not to the current state. The latter would be impossible. And kills the whole idea, right?

But ... ...What I totally forgot is this:

Code: Select all

v10.10.0102 - 2011-08-23 12:19
    + Custom Copy: Now you can state a [b]Custom Copy Blacklist[/b] containing 
      any number of target paths which shall be excluded from Custom 
      Copy (and automatically use normal Shell Copy instead).
      The data should be provided in a file placed in <xydata> and 
      named "CustomCopyBlacklist.dat". The paths should be listed one 
      per line in any order. All sorts of variables and portable syntax 
      are supported. Here's an example for the contents of the file on 
      64-bit Windows (on 32-bit Windows you would drop the line 
      "%ProgramFiles(x86)%"):
        %ALLUSERSPROFILE%
        %ProgramFiles%
        %ProgramFiles(x86)%
        %WinDir%
      The typical reason for blacklisting folders is that Custom Copy 
      will fail where UAC disallows writing to them, whereas Shell Copy 
      will prompt for elevation.

and later:

Code: Select all

v10.10.0103 - 2011-08-23 20:52
    * Custom Copy Blacklist: Now you have to append an * (asterisk) to 
      mark a folder as being blacklisted including all subfolders.
      An example using recursive and non-recursive paths:
        %HOMEDRIVE%
        %ALLUSERSPROFILE%*
        %ProgramFiles%*
        %ProgramFiles(x86)%*
        %WinDir%*

[Marco]

Maybe a "stealth" clone of ...

This is what I meant with copy instance. Another instance with the same, but read only settings, to be closed right after the elevated stuff is done.

Thanks for the pointer.


Cheers,
Filehero

Exactly (with stealth I meant that it shouldn't touch any setting on disk). And as Don says it cannot be a mirror of the current state in memory but only a mirror of the current state on disk: I suppose it would still be better than a virgin config.
Maybe at the end

Code: Select all

/fresh
Loads XY with
the current (ie. from the calling instance) registration info
OR
the reg.info contained in the default ini (Data/XYplorer.ini),
AND
nothing else, ie. bare/default/factory unlocalized config
PLUS
ActionLog and SaveSettingsonExit unchecked/set off

/clone
Loads XY with
the current (ie. from the calling instance) full config and localization
OR
the full config in the default ini (Data/XYplorer.ini) (and localization, would be specifiable?)
OR
the full config contained in the specified ini (/ini=Jason.ini) (and localization, would be specifiable?),
AND
any form of saving settings on disk (action log, tags, history, thumbs, whatever) internally disabled

/clone would be similar to the incognito/porn mode of webbrowser and would be similar also to the Tabsets feature that allows loading a tabset as a clone.
It would be useful for loading a temporary copy/mirror of your customized configuration and doing stuff without leaving traces in history nor modifying anything.

/fresh would be the way for debugging, since it loads all the default settings, and if it is called as (per changelog)

C:\Programs\XYplorer\XYplorer.exe /ini="%temp%\XY_<date yyyymmddhhnnss>\"

even the save settings "circuits" can be tested without any risk of overwriting settings.

Just my 0.02€

[admin]

Confused. What problem is still open, resp. what would be solved by /clone?

[Marco]

Confused. What problem is still open, resp. what would be solved by /clone?

From Filehero suggestion

Question: could the solution/approach described in here be used to address the "needs admin rights"-issue in a rationale way? I know in essence this is the "start new elevated instance"-approach. But if done that way, I really could life with it. Especially since all information I could get officially and from "the underground" end up with the same conclusions, that is - yes, you guess right - "restart your stuff elevated".

So: can we marry the "New /fresh switch"-approach and the "need-admin-rights"-case in a way not changing the current settings of the instance the call originates from? Basically it would be a "disposable" copy instance with elevated access rights.