git stash push => "warning: failed to restrict file handles (5)"

[rbeurskens]

$ git stash push
warning: failed to restrict file handles (5)

handle #0: 00000000000002a4 (type 2, handle info (1) 0
handle #1: 0000000000000228 (type 3, handle info (1) 1
handle #2: 00000000000001e4 (type 2, handle info (1) 1

This is a bug; please report it at
https://github.com/git-for-windows/git/issues/new

To suppress this warning, please set the environment variable

        SUPPRESS_HANDLE_INHERITANCE_WARNING=1

Saved working directory and index state WIP on <mylocalbranchname>:  <commit> <commit description>

$ git version
git version 2.48.1.windows.1

[dscho]

@rbeurskens can you share more details about this? The (5) suggests ERROR_ACCESS_DENIED, which might be caused by a file still being opened in an editor while git stash wants to modify it, for example.

[rbeurskens]

Could be, but when I could not reproduce it. Unless there are logs somewhere. I can only add I executed the command in the terminal within Visual Studio while the solution was open, so it could be VS was holding a lock. I wish I could share more.

[dscho]

@rbeurskens that would make sense. Please note that I have merged #5460 which should prevent the warning in the future (but Git still won't be able to do anything about the lock).

[rbeurskens]

I understood the warning can be suppressed by setting the environment variable. If a Git operation failed because of this I would like to know. That's what warnings are for, right? Or is this a warning that does not indicate failure? (though the phrase "this is a bug, please report" got me confused)

[dscho]

If a Git operation failed because of this I would like to know. That's what warnings are for, right?

Right. In this instance, it was some defensive programming hailing back from the time when Git for Windows still supported Windows 7, where the underlying logic to restrict handle inheritance was not available, and I wanted to be extra careful in case there were corner-cases even in newer Windows versions where that logic would fail.

However, it turned out that those corner-cases did not exist, and I was too cautious, and the warnings triggered under circumstances where the error had nothing to do with the logic but more with file locking issues that are so common on Windows. Therefore, the warning was actually misleading, and had to go.

Does that clarify the situation?