XYCopy 2.0 and UAC

[Brother John]

Overall I love XYCopy 2.0, but there’s one thing that bugs me. I can’t copy to locations where I don’t have write permissions anymore. Assume I’m logged in as user brotherjohn (a non-admin account) and copy a file from C:\Users\brotherjohn\Desktop (where brotherjohn has write access) to C:\Program Files (where brotherjohn does not have write access).

Old behaviour with OS copy: Usual UAC prompt appears, asks for admin credentials and then continues the operation. XYCopy 2.0 behaviour: The operation immediately aborts with a "Copying Failed. Acces denied" error.

Would it be possible to make XYCopy behave like OS copy? Atm I have to use Win Explorer instead or start a second Xplorer instance with admin priviledges or not use XYCopy 2.0. But none of those is a great solution.

Btw: OS is Win 7 Home Premium 64bit and XYplorer is of course 10.00.

[admin]

Difficult. I've spend the better part of the afternoon researching and testing this without success.

It is this dialog I would like to get but cannot:

"You need to confirm this operation."
(Continue Skip Cancel)

At this point I think it is not possible. The CopyFile API is just from another world, whereas UAC is shell. So for these cases you will have to use the normal (shell) copy in XYplorer (hey, no need to run Explorer).

[ugus]

A workaround instead of getting the UAC promt could be to use
the RUNAS command and run XYCOPY with that.

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

Another way is to use CreateProcessWithLogonW

http://msdn.microsoft.com/en-us/library ... s.85).aspx

So if the user needs to copy to an area which will fire the UAC promt then
run XYCOPY with CreateProcessWithLogonW

[ugus]

Maybe its also possible to get the app (XYCopy) to display the UAC prompt?

A google search on this topic

UAC elevation code
displays some examples...

It seems that a manifest like this and some coding will display the UAC prompt?

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity version="1.0.0.0"  name="ElevationTest" type="win32"/>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="requireAdministrator"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

[admin]

Thanks, I know the RUNAS trick, but it comes out so clumsy that I decided it's not workable. Also the manifest stuff is just another route to the same results. What I would need is the dialog I mentioned.

[ugus]

Thanks, I know the RUNAS trick, but it comes out so clumsy that I decided it's not workable. Also the manifest stuff is just another route to the same results. What I would need is the dialog I mentioned.

But does not the manifest trick make Windows 7 display the UAC prompt when necessary for the app?

http://www.aneef.net/2009/06/29/request ... aged-code/

This code seems to fire up the UAC prompt when needed...

[admin]

Thanks, I know the RUNAS trick, but it comes out so clumsy that I decided it's not workable. Also the manifest stuff is just another route to the same results. What I would need is the dialog I mentioned.

But does not the manifest trick make Windows 7 display the UAC prompt when necessary for the app?

http://www.aneef.net/2009/06/29/request ... aged-code/

This code seems to fire up the UAC prompt when needed...

Hm, what makes you think so. I don't see a screenshot of the prompt I want. And even if it would work: forcing XYcopy by manifest to run as administrator is not a good solution I think.

This is the prompt I want.

UAC_AccessDenied.png (23.03 KiB) Viewed 2846 times

This is NOT the prompt I want.

UAC_AccessDenied2.png (19.86 KiB) Viewed 2846 times

[ugus]

OK, I thought you wanted this prompt...

"UAC_AccessDenied2.png"

BTW, Dopus fires up this UAC prompt when copying to an UAC protected area.

I think this is the standard Windows behaviour. AFAIK you cannot bypass this prompt
(if you don't disable the Windows UAC control....)

So why is this dialog so bad? It allows you to continue. At the moment XY custom copy fails.

EDIT:
It is only when user has local admin rights you get this prompt anyway? Otherwise you'll have access denied.

[Brother John]

@Don
Thx for the hint with shell copy. I didn’t think of the shell context menu and its copy functions. That’s a workaround I can live with!

I also agree that UAC_AccessDenied.png needs to appear first because it has all the relevant information to decide if you want to continue or not. That’s usually not the case for UAC_AccessDenied2.png. If that’s not possible I actually prefer the current behaviour. After all copying to read-only locations isn’t something you do that regularly.

@ugus
I know shell copy to work like this: If your user has local admin rights then the two dialogs Don posted appear one after the other. If your user does not have local admin rights it’s the same seqeunce only with the version of UAC_AccessDenied2.png that asks for an admin login.

[admin]

OK, I thought you wanted this prompt...

"UAC_AccessDenied2.png"

BTW, Dopus fires up this UAC prompt when copying to an UAC protected area.

I think this is the standard Windows behaviour. AFAIK you cannot bypass this prompt
(if you don't disable the Windows UAC control....)

So why is this dialog so bad? It allows you to continue. At the moment XY custom copy fails.

EDIT:
It is only when user has local admin rights you get this prompt anyway? Otherwise you'll have access denied.

It's bad because it is unexpected at this point, because it says "Herausgeber: Unbekannt" (Publisher: Unknown) which is there because I refuse to pay hundreds of dollars just to have my name there, and because of internal technical reasons (it is very hard to get the return codes of this dialog).

[admin]

@Don
Thx for the hint with shell copy. I didn’t think of the shell context menu and its copy functions. That’s a workaround I can live with!

Not only shell context menu. All copy operations in XY are using the shell copy UNLESS you opt for the new Custom Copy. If you add the "Use Custom Copy" button to your toolbar you can quickly switch back and forth between shell copy and custom copy.

[ugus]

OK

Thanks for the info.

Then a reasonable workaround if you want to copy to UAC protected area is to
temporarily toggle the Custom Copy toolbar off

[nas8e9]

@Don
Thx for the hint with shell copy. I didn’t think of the shell context menu and its copy functions. That’s a workaround I can live with!

Not only shell context menu. All copy operations in XY are using the shell copy UNLESS you opt for the new Custom Copy. If you add the "Use Custom Copy" button to your toolbar you can quickly switch back and forth between shell copy and custom copy.

I wonder whether this can be automated: if set to use Custom Copy but the target requires elevation, automatically pawn only that job off to shell copy?

It's not a perfect solution, but it would save end users the face palm/RSI-moment of having to dismiss the Custom Copy dialog, switch off Custom Copy and start from scratch, to be followed by re-enabling Custom Copy. I tend to do work in protected areas at least a few times per week, which to me would make such an automated workaround, desirable.

It's bad because it is unexpected at this point, because it says "Herausgeber: Unbekannt" (Publisher: Unknown) which is there because I refuse to pay hundreds of dollars just to have my name there, and because of internal technical reasons (it is very hard to get the return codes of this dialog).

1. It deviates from the expectation set by Windows Explorer but not other FM's: they too need to elevate first.
2. The digital certificate stuff is a (well, your... ) business decision. I'm under the impression that both security software as well as browser security mechanisms, have started favouring digitally signed files, but whether that merits your investment?
3. Do you mean the process trying to spawn an elevated process, gets next to no notification of whether consent was granted and the process could thus be run?

[admin]

@Don
Thx for the hint with shell copy. I didn’t think of the shell context menu and its copy functions. That’s a workaround I can live with!

Not only shell context menu. All copy operations in XY are using the shell copy UNLESS you opt for the new Custom Copy. If you add the "Use Custom Copy" button to your toolbar you can quickly switch back and forth between shell copy and custom copy.

I wonder whether this can be automated: if set to use Custom Copy but the target requires elevation, automatically pawn only that job off to shell copy?

It's not a perfect solution, but it would save end users the face palm/RSI-moment of having to dismiss the Custom Copy dialog, switch off Custom Copy and start from scratch, to be followed by re-enabling Custom Copy. I tend to do work in protected areas at least a few times per week, which to me would make such an automated workaround, desirable.

It's bad because it is unexpected at this point, because it says "Herausgeber: Unbekannt" (Publisher: Unknown) which is there because I refuse to pay hundreds of dollars just to have my name there, and because of internal technical reasons (it is very hard to get the return codes of this dialog).

1. It deviates from the expectation set by Windows Explorer but not other FM's: they too need to elevate first.
2. The digital certificate stuff is a (well, your... ) business decision. I'm under the impression that both security software as well as browser security mechanisms, have started favouring digitally signed files, but whether that merits your investment?
3. Do you mean the process trying to spawn an elevated process, gets next to no notification of whether consent was granted and the process could thus be run?

The problem: I don't know how to detect whether the target requires elevation.

3. Yes. At least I don't know how to get this notification. There is next to no documentation on this.

[nas8e9]

The problem: I don't know how to detect whether the target requires elevation.

FWIW, this post on StackOverflow suggests opening the (first) file for writing. If this throws an error, providing it can be handled silently, one could try an alternative action, i.e. Windows Shell copy. One caveat is that UAC virtualisation on Vista and later, makes writing to certain locations silently fail in the sense of redirecting the write, with those locations listed here, meaning those locations would have to be hard-coded exceptions to Custom Copy.

Regardless of the above test, would it be an idea to hard-code those exceptions in Custom Copy? I'd guess that covers most cases where lack of file permissions cause a problem, although people disabling UAC wouldn't need this of course.