XYCopy 2.0 and UAC

[admin]

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.

Or let the user add a list of folders where shell copy would be used?

[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.

Or let the user add a list of folders where shell copy would be used?

A user-defined Custom Copy blacklist with perhaps the UAC virtualisation folders included as factory-default, sounds good to me.

[admin]

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.

Or let the user add a list of folders where shell copy would be used?

A user-defined Custom Copy blacklist with perhaps the UAC virtualisation folders included as factory-default, sounds good to me.

You mean these?
%Program Files%
%WinDir%
%WinDir%\System32

[nas8e9]

A user-defined Custom Copy blacklist with perhaps the UAC virtualisation folders included as factory-default, sounds good to me.

You mean these?
%Program Files%
%WinDir%
%WinDir%\System32

Yes, and additionally %ALLUSERSPROFILE% isn't user-writable and on 64-bit Windows, %ProgramFiles(x86)% would also qualify.

[highend]

A user-defined Custom Copy blacklist with perhaps the UAC virtualisation folders included as factory-default, sounds good to me

+1

[eil]

Or let the user add a list of folders where shell copy would be used?

i don't really need it at the moment, but i feel it's a good feature

[admin]

A user-defined Custom Copy blacklist with perhaps the UAC virtualisation folders included as factory-default, sounds good to me.

You mean these?
%Program Files%
%WinDir%
%WinDir%\System32

Yes, and additionally %ALLUSERSPROFILE% isn't user-writable and on 64-bit Windows, %ProgramFiles(x86)% would also qualify.

Would this also include all subfolders of these dirs?

[highend]

Inheritance is activated automatically so yes, all subfolders have the same access rights (at least for system folders, it can be different for the %allusersprofile% dir).

[admin]

Inheritance is activated automatically so yes, all subfolders have the same access rights (at least for system folders, it can be different for the %allusersprofile% dir).

So %WinDir%\System32 does no have to be listed because it is implied with %WinDir% anyway.

[highend]

So %WinDir%\System32 does no have to be listed because it is implied with %WinDir% anyway.

Correct.

[nas8e9]

The root of the boot drive (on Vista and later always C:) also isn't user-writable. I'm not sure how the drive letter of the boot drive can be checked programmatically; should that be impossible, C: hardcoded would probably be the most pragmatic solution.

Unfortunately, the above would need to be an exception to the rule that exclusions are inherited from the top object.

Finally, the CustomCopyBlacklist.dat-file isn't yet included in the installer?

[admin]

The root of the boot drive (on Vista and later always C:) also isn't user-writable. I'm not sure how the drive letter of the boot drive can be checked programmatically; should that be impossible, C: hardcoded would probably be the most pragmatic solution.

Unfortunately, the above would need to be an exception to the rule that exclusions are inherited from the top object.

Finally, the CustomCopyBlacklist.dat-file isn't yet included in the installer?

Hmm, simple things quickly attract complications... One might append a * to the paths that shall be blacklisted recursively.

Not sure if I should add it to the installer. I rather let it ripen first in the scarred hands of selected power users.

[nas8e9]

The root of the boot drive (on Vista and later always C:) also isn't user-writable. I'm not sure how the drive letter of the boot drive can be checked programmatically; should that be impossible, C: hardcoded would probably be the most pragmatic solution.

Unfortunately, the above would need to be an exception to the rule that exclusions are inherited from the top object.

Finally, the CustomCopyBlacklist.dat-file isn't yet included in the installer?

Hmm, simple things quickly attract complications... One might append a * to the paths that shall be blacklisted recursively.

At first sight the root of the boot drive, is the only one that shouldn't be handled recursively. Perhaps only marking the exception to the rule with a "*"?

Not sure if I should add it to the installer. I rather let it ripen first in the scarred hands of selected power users.

Got it.

[admin]

At first sight the root of the boot drive, is the only one that shouldn't be handled recursively. Perhaps only marking the exception to the rule with a "*"?

Since the list is open for any user-specific additions and since an appended * (at least to me) seems a quite natural way to say "including all contents" I would rather stay with my initial suggestion. But maybe further still invisible complications will call for yet another way...

[nas8e9]

At first sight the root of the boot drive, is the only one that shouldn't be handled recursively. Perhaps only marking the exception to the rule with a "*"?

Since the list is open for any user-specific additions and since an appended * (at least to me) seems a quite natural way to say "including all contents" I would rather stay with my initial suggestion. But maybe further still invisible complications will call for yet another way...

I forgot the general meaning of "*" as a wildcard. Sounds good to me.