Bug - Git reset --quiet not quiet

Good afternoon,

When running this command on Git for Windows (version 1.9.2-preview20140411) git reset --quiet --hard with one file having read/write lock git ask this question : Unlink of file 'XXXX' failed. Should I try again? (y/n)

I will have expected the command --quiet to remove the question and auto-answer no. This broke an automated script we use.

Good day

Thomas-Louis Laforest, ing. jr, Jr. Eng. Chargé de projet, Project Leader solutions intégrées  |  integrated solutions T 819 542-5600  x3106 F 819 845-5600 tllaforest@arbault.ca The information contained herein is of private and confidential nature. It can be used only by the above-mentioned recipients. Any other person who would take note of it is advised that it is strictly forbidden for him to reveal the information, to distribute it or to copy it. If this communication were transmitted to you by mistake, warn us immediately by telephone or email, and erase the original, without taking a copy, revealing the content nor taking some measures based on it. Les renseignements contenus dans les présentes sont de nature privée et confidentielle. Ils ne peuvent être utilisés que par le ou les destinataires susmentionnés. Toute autre personne qui en prendrait connaissance est priée de noter qu'il lui est strictement interdit de les divulguer, de les distribuer ou de les copier. Si cette communication vous a été transmise par mégarde, veuillez nous en aviser immédiatement par téléphone ou par courriel, et effacer l'original, sans en tirer de copie, en dévoiler le contenu ni prendre quelque mesure fondée sur celui-ci.

On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest <tllaforest@arbault.ca> wrote:

Thanks for reporting this.

The problem here is really a nasty case of layering: the question comes from a place deep inside the OS compatibility layer, which doesn't know about the --quiet flag.

However, do note that if fixed, the command would still fail under these conditions. But it won't hang forever, as it does now.

Mainline Git-folks: The problem here is essentially unlink returning EBUSY (although that's not *exactly* what happes - but it's close enough, implementation details in mingw_unlink), which most of the git codebase assume won't happen. On Windows, this happens *all* the time, usually due to antivirus-software scanning a newly written file. We currently retry a few times with some waiting in mingw_unlink, and then finally prompts the user. But this gives the problem described above, as mingw_unlink has no clue about --quiet.

I guess this could be solved in a few ways.
1) Let mingw_unlink() know about the quiet-flag. This probably
involves moving the quiet-flag from each tool into libgit.a.
2) Make the quiet-flags close stdout instead of suppressing every output.
3) Make the higher level call-sites of Git EBUSY-aware. This probably
involves making an interactive convenience-wrapper of unlink, that
accepts a quiet flag - similar to what mingw_unlink does.

Option 1) seems quite error-prone to me - it's difficult to make sure all code-paths actually set this flag, so there's a good chance of regressions. Option 2) also sounds a bit risky, as we lose stdout forever, with no escape-hatch. So to me option 3) seems preferable although it might translate into a bit of churn. Thoughts?

Am 5/13/2014 11:09, schrieb Erik Faye-Lund:

...

Is any of this really needed? We have this in ask_yes_no_if_possible():

	if (!isatty(_fileno(stdin)) || !isatty(_fileno(stderr)))
		return 0;

i.e., we answer "no" automatically without asking if at least one of stdin and stderr are not a terminal. Perhaps the OP's problem is that they do not redirect these channels to files or something in their automated scripts? In particular, it should be sufficient to redirect stdin from /dev/null (a.k.a. "nul" on Windows).

-- Hannes

On Tue, May 13, 2014 at 11:38 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:

Well, sure. But if sounds like surprising behavior to me. And I also suspect doing this unconditionally on all platforms will fix strange corner-cases on other systems, when using Windows file-systems. AFAIK, the whole "cannot delete an open file"-thing is an NTFS-detail (and possibly also FAT, which is quite commonly used on non-Windows).