microsoft / sudo

It's sudo, for Windows

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

When running sudo command with "in new window" config, it doesn't launch in a new window.

AvogatoWizardWhisker opened this issue · comments

Sudo for Windows version

sudo 0.1.5

Windows build number

10.0.26052.1000

Other Software

No response

Steps to reproduce

When I use the sudo command to run robocopy, I see a prompt that says "Launched robocopy in a new window", but no new window appears and the command fails to execute.

image

Expected Behavior

I expected Windows Terminal to open a new window and run the robocopy command.

Actual Behavior

"Launched robocopy in a new window" prompt and the robocopy command didn't work

Recording.2024-02-12.180940.mp4

Hmm.

Can you share the output of:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Sudo /v enabled

When you do launch sudo robocopy ..., do you get the UAC prompt? (those obviously don't show up in screen recordings) If so, does the UAC show up for sudo.exe -p {something} robocopy..., or is it for robocopy .../?

image
When i launched sudo, UAC did pop up, but it showed for Microsoft Robocopy, not sudo. When i clicked on yes, a window showed up in millisecond then it closed.

Hmm. I'd reckon that we're accidentally detecting that robocopy is a windows exe, rather than a console one1. Weirdly, I can't repro this locally - I definitely get a UAC for sudo. Lemme go double check with the binary straight from the Insiders build

Footnotes

  1. for something like notepad.exe, we'll just launch the target app elevated (since it doesn't really need a console).

(as a sanity check, does sudo cmd /k robocopy .... work as expected? That might help ID what the error message is, if robocopy is running then bailing immediately, closing the console)

the sudo cmd command you provided did work , and UAC did pop up for Sudo

Recording.2024-02-13.164257.mp4

After testing various options, I found that the behavior of ‘in a new window’ is not functioning as expected. When I used the ‘inline’ and ‘With input disabled’ settings, the User Account Control (UAC) prompt appeared for Sudo. However, when I opted for the ‘In a new window’ configuration, the UAC prompt specifically appeared for robocopy. In my previous recording, I utilized the ‘With input disabled’ setting, while in the initial video, I employed the ‘In a new window’ configuration. I apologize for any confusion.
image

Aha! Well yep, that'd at least explain that. Okay, that settles some concern of mine, about mis-detecting robocopy.

Curious that in the "new window" mode, it didn't copy the files. I'd suspect that robpcopy would have launched in the new console window, ran, and then exited (likely pretty quickly), and immediately the console window closed. But the files should have been copied?

For some unknown reason, the files were not successfully copied. The newly opened window promptly closed right after it appeared.

Unrelated issue I discovered

Oh man I know what happened. You can see for yourself with sudo --newWindow cmd /k echo uh oh
image

I'd reckon the bog-standard ShellExecute("runas", args...) runs that target application in system32 by default, NOT in {{wherever you started}}. We are passing the CWD to the ShellExecute call, but that's clearly been ignored.


I typed all that up and realized it was unrelated. Still not sure why that didn't work...

Is there some place i can check the events done with sudo commands? I can't seem to find anything in Event Viewer.

Is there some place i can check the events done with sudo commands? I can't seem to find anything in Event Viewer

They should be under "Applications and Services Logs" -> "Microsoft" -> "Windows" -> "Sudo" -> "Admin", though, there was a series of builds of sudo where that didn't quite work. I don't think it was hooked up right in the original release (though, it should be working today in our local branch).

another quick way of checking that is wevtutil qe Microsoft-Windows-Sudo/Admin /c:3 /rd:true /f:text (though, again, that won't work until builds like 3 weeks from today)


FWIW, I can't repro this locally on more current builds of sudo
image

nor can I with the 0.1.5 version of sudo:
image

I wonder if there's robocopy logs somewhere we can check to see if there's a reason the robocopy didn't work for you?

Weirdly I do not have events saved for sudo. Same thing for robocopy. Was i supposed to add events manually?

image

Nah, that sounds about right. I think the Event Viewer logs got delayed from the original release. Looking at the commits, the build of sudo that added event viewer support also had a bug that broke our event viewer support, and the fix is a few weeks out.

Just to sanity check myself - it's been a couple weeks and there are a few new preview builds that have gone out. What OS build and sudo version are you on now?

Does sudo --new-window robocopy ... work for other directories?

It does look like robocopy supports a /LOG:file parameter to log status to a file - if you add that, does that log file have anything interesting in it?

I'm currently running the latest Canary build 10.0.26063 and the sudo version is 0.1.5. I added the /log on robocopy. It didn't show anything interesting; it only showed if there's a new file directory, new file and such. Like what robocopy usually do.

PS: the option is --newWindow not --new-window 😊.

image

image

PS: the option is --newWindow not --new-window 😊.

ah my b, we changed that flag between 0.1.5 and 1.0.

It didn't show anything interesting

But it does look like it copied the files, right? Like, that output suggests to me that robocopy did run, so the files should be there. Looks like 340 of the files were copied, while 4337 of them didn't need to be.

Yeah, it did copy files since it only copied 2 new folders (they're 62MiB big) and the existant folders were remained untouched.

Great so, it sounds like everything is working! Thanks for the follow ups ☺️