Git 2.24 breaks existing repositories: filename in tree entry contains backslash #2435
Comments
carlescufi
changed the title
|
@carlescufi did you find out which tree entries those might be? They really cannot be checked out on Windows as expected: if there is a backslash encoded in any file name in that repository, it will be mistaken for a directory separator on Windows, which is obviously not what we want here. |
One commit with a bad file is zephyrproject-rtos/civetweb@9d3af98 which adds a
No attempt is made to check out a file with a backslash when cloning the latest master. And indeed, though However, this That seems inconsistent and arguably wrong: since we can clone the repository without an error return code (just error messages), we should be able to fetch it, too, just not check out the bad revisions. |
|
@dscho as @mbolivar pointed out there is no longer any file in the repository with a backslash in its name. This means that, short of changing the behavior of Git for Windows in an upcoming release, the only other alternative is to rewrite the history of the tree to completely remove any traces of commits that introduced filenames with backslashes. This might be very cumbersome on some repositories. |
|
@carlescufi & @mbolivar I am sympathetic to your use case. However, I am still worried about lifting the protections that we carefully put in place. So I'd like to tread very, very carefully here. To start us in a direction that hopefully will lead to an acceptable compromise that still keeps the Git for Windows users safe, but also allows users to clone civetweb as long as they do not try to check out commits with the inadmissible directory name, I opened #2437. |
|
@dscho thank you for the understanding and the PR. Please let us know when we can fetch a binary from CI so we can test it ourselves and give a +1. |
Whoa. I would like to ask even more explicitly for help with thinking about the problem. Maybe you can give a hand with reviewing the code and trying to get it into a shape where we can be reasonably sure that it does not regress on the vulnerabilities? Before that, I won't even bother with thinking about binaries. |
Sorry, since you had posted a Pull Request I assumed that you had considered those already. I will take a look at the current PR with @mbolivar and give feedback here. |
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses git-for-windows#2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses git-for-windows#2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses git-for-windows#2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' The idea is to prevent Git from even trying to write files with backslashes in their file names: while these characters are valid in file names on other platforms, on Windows it is interpreted as directory separator (which would obviously lead to ambiguities, e.g. when there is a file `a\b` and there is also a file `a/b`). Arguably, this is the wrong layer for that error: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's loosen the requirements: we now leave tree entries with backslashes in their file names alone, but we do require any entries that are added to the Git index to contain no backslashes on Windows. Note: just as before, the check is guarded by `core.protectNTFS` (to allow overriding the check by toggling that config setting), and it is _only_ performed on Windows, as the backslash is not a directory separator elsewhere, even when writing to NTFS-formatted volumes. An alternative approach would be to try to prevent creating files with backslashes in their file names. However, that comes with its own set of problems. For example, `git config -f C:\ProgramData\Git\config ...` is a very valid way to specify a custom config location, and we obviously do _not_ want to prevent that. Therefore, the approach chosen in this patch would appear to be better. This addresses git-for-windows#2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' The idea is to prevent Git from even trying to write files with backslashes in their file names: while these characters are valid in file names on other platforms, on Windows it is interpreted as directory separator (which would obviously lead to ambiguities, e.g. when there is a file `a\b` and there is also a file `a/b`). Arguably, this is the wrong layer for that error: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's loosen the requirements: we now leave tree entries with backslashes in their file names alone, but we do require any entries that are added to the Git index to contain no backslashes on Windows. Note: just as before, the check is guarded by `core.protectNTFS` (to allow overriding the check by toggling that config setting), and it is _only_ performed on Windows, as the backslash is not a directory separator elsewhere, even when writing to NTFS-formatted volumes. An alternative approach would be to try to prevent creating files with backslashes in their file names. However, that comes with its own set of problems. For example, `git config -f C:\ProgramData\Git\config ...` is a very valid way to specify a custom config location, and we obviously do _not_ want to prevent that. Therefore, the approach chosen in this patch would appear to be better. This addresses git-for-windows#2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
I have this issue with Jenkins as well, but I have no idea how to implement the workaround, as I don't see a setting for the plugin or a way to use the GitSCM class to work around this. 'bat' script block with the workaround also do not work. https://issues.jenkins-ci.org/browse/JENKINS-60632 Edit: Tracking the relevant PRs for resolution in addition to the above.
If we are ok with wiping the commit with the offending blackslash-named files from history, how can this be done if we want to fix this now? I've tried |
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses git-for-windows#2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
Could y'all please test https://github.com/git-for-windows/git/releases/tag/v2.25.0-rc1.windows.1? @mtdeguzis If you could test, too? And if successful, recommend to upgrade to v2.25.0 for the affected parties (Git for Windows v2.25.0 is expected to land on January 13th, i.e. 10 days from now)? |
This solves the problem on my end. The fetch completes without warning or error. Thanks! |
|
@mbolivar could you also, just for shiggles, try to check out the faulty revision? (It should fail) |
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses #2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I'm not sure how I can test since mine is affected by Jenkins git plugin. I will test as much as possible though. |
|
@mtdeguzis I thought you would have the option of bundling Git for Windows with the plugin (or if not, be able to install the -rc version on the machine running Jenkins)? |
2.25.0.rc1 works for me. Had error |
|
@aaniin thank you for confirming! |
|
@dscho I can confirm this fixes the issue using Git Bash under v2.25.0-rc1.windows.1 and the Jenkins git plugin. Those using Jenkins can also refer to https://issues.jenkins-ci.org/browse/JENKINS-60632. |
|
Excellent. Thanks, @mtdeguzis! |
Confirmed; it fails. HEAD remained the same after the checkout. |
|
Thank you @mbolivar! |
|
Fixed in v2.25.0-rc1 via git@224c7d7. |
It is [again possible](git-for-windows/git#2435) to clone repositories where _some_ past revision contained file names containing backslashes (Git will of course still refuse to check out such revisions). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
@dscho thank you for all the work on this issue. |
A bug in Git for Windows V2.24 does not allow to checkout CivetWeb: git-for-windows/git#2435 Possible workaround: Disable core.protectNTFS: git config --global core.protectNTFS false Solution: Use Git for Windows <= V2.23 or >= V2.25
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses #2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses #2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses #2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' While the clone still succeeds, a similar error prevents the equivalent `git fetch` operation, which is inconsistent. Arguably, this is the wrong layer for that error, anyway: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's instead prevent such files to be added to the index. This addresses #2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
When I am trying to clone this repo: https://github.com/vinhphunguyen/MPM-Julia Also, This repo seems created in macOS, and has strange filename such as: |
|
see also #2438 |
and others
What are users supposed to do here, rewrite the history of the repos so that the offending commit is removed?
The workaround is to disable core.protectNTFS:
git config --global core.protectNTFS falseSetup
Git for Windows 2.24.1.windows.2 64-bit
defaults?
to the issue you're seeing?
Installed with Chocolatey
Details
cmd.exe
Minimal, Complete, and Verifiable example
this will help us understand the issue.
Cloned repo successfully.
URL to that repository to help us with testing?
https://github.com/zephyrproject-rtos/civetweb.git
The text was updated successfully, but these errors were encountered: