Feature: Added support for elevated file operations

[gave92]

Resolved / Related Issues

• Were these changes approved in an issue or discussion with the project maintainers? In order to prevent extra work, feature requests and changes to the codebase must be approved before the pull request will be reviewed. This prevents extra work for the contributors and maintainers.
  Closes Feature: Implement support for elevated operations #10422

Validation
How did you test these changes?

• Did you build the app and test your changes?
• Did you check for accessibility? You can use Accessibility Insights for this.
• Did you remove any strings from the en-us resource file?
  • Did you search the solution to see if the string is still being used?
• Did you implement any design changes to an existing feature?
  • Was this change approved?
• Are there any other steps that were used to validate these changes?
  1. Test copy, pasting, renaming, deleting, creating a file in C:

This PR (re)adds basic support for performing file operations as admin using a separate process. This is meant as a stopgap while we wait for a fix to microsoft/WindowsAppSDK#3092.
To keep things simple: no progress, no cancellation, no undo/redo, no error feedback.

Screenshots (optional)

[yaira2]

To keep things simple: no progress, no cancellation, no undo/redo, no error feedback

Should we notify the user beforehand that it won't be available? Alternatively, would it be easy to display File Explorers transfer UI in this case?

[gave92]

Well you still see that the operation is ongoing in the status center.

Maybe we can show "Progress not available" instead of the progress line and disable the cancel button?

would it be easy to display File Explorers transfer UI in this case?

This is also possible

[gave92]

Wait I'm feeling like an idiot. Lemme try one thing.

[gave92]

Ook realized there was a better way to do this. No need for a separate process and still get progress, undo/redo and error reporting :)

[yaira2]

LGTM

[yaira2]

@gave92 Thank you for working on this, it's has been a pain point since migrating to WinAppSdk and I know a lot of people are going to be very happy it's resolved.

[gave92]

Is it just me or does this thing not work anymore? :/ Even checking out this PR admin operations fail.

[yaira2]

It prompts for access but then fails to do the operation.

[gave92]

Uff was it a change in windows then? Could swear it was working grr.

[yaira2]

I know it was working, I tested before merging 😄

[gave92]

Confirmed: "KB5028185 Windows 11 Cumulative Update Build 22621.1992" breaks admin file operations for packaged apps. Just tried to go back to build 22621.1848 and tadaaa admin operations work again 😢. @yaira2 do you think we can notify anyone about this?

[yaira2]

Is there an issue or post from Microsoft about this regression?

[gave92]

None that I can find. Not sure where we'd file such a bug report. Maybe we could ask in the "winui" channel of "UWP Community" on discord?

[riverar]

I can't reproduce this on 10.0.22621.2134, can you see if this works for you? You should end up with a test.txt in C:\Windows.
app.zip

[gave92]

Thanks! But note that the issue is only with Packaged apps. For un-packaged apps it still works.

[riverar]

Still can't reproduce this issue outside of Files, there's certainly no indication of an OS issue. Maybe there's a Files threading issue at play here?

[gave92]

Will send repro app, thanks for checking. Could you also share the code you're using to repro?

Packaged the app and can reproduce failure

Can you repro for Packaged apps then?

[riverar]

Can you repro for Packaged apps then?

No, sorry for the confusion. When I posted that comment, my app was running in lowIL due to a manifest typo (that interestingly enough didn't cause an error). I since fixed that and now cannot reproduce.

Latest compiled sample: packaged_app.zip
Code: https://github.com/riverar/repro-1012c50820aa (Run ./Package.ps1)

[hishitetsu]

When I run it in debug, it appears that the file operation has been processed before the UAC prompt appears and fails with an authorization error.

[hishitetsu]

Attempting to perform a elevated file operation will result in the following exception. Would this be of any help in the analysis?

[gave92]

Given that it used to work, this looks like an MS bug. I'm not sure we can fix it :(

[hishitetsu]

I know it used to work too.
@yaira2 If this issue is not resolved by the time v3 is released, wouldn't it be better to revert this PR?

[gave92]

It's annoying to miss out admin ops in v3 :(

I'm tempted to take commit 7ad5f78 up again. It uses a different method and should work.

It has limitiations:

To keep things simple: no progress, no cancellation, no undo/redo

But it's better than nothing?

[hishitetsu]

It's annoying to miss out admin ops in v3 :(

Yeah but it's more annoying that admin ops fail even though clicking on the shield icon.

I'm tempted to take commit 7ad5f78 up again. It uses a different method and should work.

I'd like to try that too.

[yaira2]

It still works occasionally, @riverar suggested it could be a threading issue which would explain why it's on and off.

[hishitetsu]

Really? I have no success even if I have disabled UAC. Anyway, I think this is a blocker to release v3.