On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest <tllaforest@xxxxxxxxxx> wrote: > 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. 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html