XYplorer Beta Club

nas8e9 wrote:

admin wrote: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.

admin wrote:

nas8e9 wrote:

admin wrote: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 wrote:

admin wrote:

nas8e9 wrote:

admin wrote: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 wrote:

nas8e9 wrote: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

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

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

nas8e9 wrote:

admin wrote:

nas8e9 wrote: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 wrote: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 wrote:So %WinDir%\System32 does no have to be listed because it is implied with %WinDir% anyway.

nas8e9 wrote: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 wrote:

nas8e9 wrote: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.

admin wrote: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 wrote: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 "*"?

admin wrote:

nas8e9 wrote: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...