Skip to content

Fix std handle forwarding #1837

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix std handle forwarding #1837

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 1 addition & 4 deletions GVFS/GitHooksLoader/GitHooksLoader.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,9 +112,6 @@ int ExecuteHook(const std::wstring &applicationName, wchar_t *hookName, int argc
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
si.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
si.hStdError = GetStdHandle(STD_ERROR_HANDLE);
si.dwFlags = STARTF_USESTDHANDLES;
Comment on lines -115 to -117
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what you're saying is that this explicit redirection of stdout/stderr currently does not work? This is puzzling because the GitHooksLoader.exe process should have the correct handles, and this way of creating the child process should work...

Copy link
Contributor Author

@tyrielv tyrielv May 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does not work. For example running git status on an unmounted gvfs repo displays only the standard fatal: pre-command hook aborted command message, and not the specific message about needing to mount.

The documentation for CREATE_NO_WINDOW says The process is a console application that is being run without a console window. Therefore, the console handle for the application is not set.


ZeroMemory(&pi, sizeof(pi));

Expand All @@ -135,7 +132,7 @@ int ExecuteHook(const std::wstring &applicationName, wchar_t *hookName, int argc
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
TRUE, // Set handle inheritance to TRUE
CREATE_NO_WINDOW, // Process creation flags
NULL, // Process creation flags
Comment on lines -138 to +135
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I seriously wonder whether this flag is there on purpose, to avoid "flashing windows" when, say, running git.exe from Visual Studio.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I'll check that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I observed the updated hook getting called in procmon from VS, but there was no flashing window that I could see. I would expect that VS is already launching its git command with CREATE_NO_WINDOW, so the hooks loader is inheriting that state and passing it on.

NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFO structure
Expand Down