Pycharm behaving strange with Git (Filename in tree entry contains backslash)

Question

I just got a new laptop and wanted to clone my universities git repository with pycharm.

Whenever I try to clone the repository, using either Git bash/GUI or Pycharm, it fails with the error,

Filename in tree entry contains backslash: 'Aufgabe4a.py# coding=utf-8 ...

Within the error is the complete content of the mentioned file.

As this is the repo of my university, I can't just go and rename files that are not mine. The weird thing is, this doesn't happen on my desktop. I can clone the repo just fine on there.

Both machines are running Windows 10 and the latest versions of Git/Pycharm.
SSH is configured properly and I can't clone using HTTPS either.

I look forward to your suggestions, as I need this repo to hand in my exercises and don't always have access to my desktop.

Edit: There is not a single file in the repository containing a backslash in its name. I checked through the website and “working copy“, an iOS app to preview Git repos.

These are the results when debugging with Git on the laptop:

18:28:45.034704 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
18:28:45.036676 git.c:439               trace: built-in: git clone git@*removed*.git
Cloning into 'uebungen'...
18:28:45.093121 run-command.c:663       trace: run_command: unset GIT_DIR; ssh git@*university URL* 'git-upload-pack '\''*university repo*'\'''
18:28:48.140893 run-command.c:663       trace: run_command: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 8492 on DESKTOP-QNIF5QA' --check-self-contained-and-connected
18:28:48.155482 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
18:28:48.157663 trace.c:375             setup: git_dir: C:/Users/*removed*/uebungen/.git
18:28:48.157663 trace.c:376             setup: git_common_dir: C:/Users/*removed*/uebungen/.git
18:28:48.157663 trace.c:377             setup: worktree: C:/Users/*removed*
18:28:48.157663 trace.c:378             setup: cwd: C:/Users/*removed*
18:28:48.157663 trace.c:379             setup: prefix: (null)
18:28:48.158012 git.c:439               trace: built-in: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 8492 on DESKTOP-QNIF5QA' --check-self-contained-and-connected
remote:
remote: Enumerating objects: 828, done.
remote:
(...)
remote: Counting objects: 100% (828/828), done.
remote:
(...)
remote:
remote: Compressing objects: 100% (380/380), done.
remote: Total 1184 (delta 490), reused 725 (delta 430)
error: filename in tree entry contains backslash: 'Aufgabe4a.py# coding=utf-8
import random #Liste für die Auswahlmöglichkeiten für den Rechner list = ["Schere", "Stein", "Papier"] #Eingabemöglichkeit für den Benutzer print("Versuchen Sie ihr Glück in Schere, Stein, Papier!") w = (raw_input("Bitte wählen sie Schere, Stein, oder Papier:")) # if w == "Schere":     print("Sie haben Schere gewaehlt!\n") else:     if w == "Stein":         print("Sie haben Stein gewaehlt!\n")     else:         if w == "Papier":             print("Sie haben Papier geweahlt!\n")         else:             print("Sie haben keine zugelassene Eingabe getaetigt!")             exit() #Wahl des Rechners wird, sowie der Ausgang des Spiels entschieden x = list[random.randint(0, 2)] print("Ihr Gegner hat " + x + " gewaehlt!\n")  if w == "Schere":     if x == "Schere":         print("Sie haben unentschieden gespielt!")     else:         if x == "Stein":             print("Stein schleift Schere, Sie haben verloren!")         else:             if x == "Papier":                 print("Schere schneidet Papier, Sie haben gewonnen!") elif w == "Stein":     if x == "Schere":         print("Stein schleift Schere, Sie haben geweonnen!")     elif x == "Stein":         print("Sie haben unentschieden gespielt!")     elif x == "Papier":         print("Papier umfaltet Stein, Sie haben verloren!") elif w == "Papier":     if x == "Schere":         print("Schere schneidet Papier, Sie haben verloren!")     elif x == "Papier":         print("Sie haben unentschieden gespielt!")     elif x == "Stein":         print("Papier umfaltet Stein, Sie haben gewonnen!")'
fatal: Not all child objects of 9(...)c are reachable
fatal: index-pack failed

This is the debugging output on the desktop machine:

21:38:07.768170 exec-cmd.c:237          trace: resolved executable dir:C:/Program Files/Git/mingw64/bin
21:38:07.769170 git.c:440               trace: built-in: git clone git@*uni repo*.git
Cloning into 'uebungen'...
21:38:07.783173 run-command.c:663       trace: run_command: unset GIT_DIR; ssh git@*uni domain* 'git-upload-pack '\''*repo*.git'\'''
21:38:08.587244 run-command.c:663       trace: run_command: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 14672 on Leo-PC' --check-self-contained-and-connected
21:38:08.602247 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
21:38:08.604247 trace.c:377             setup: git_dir: C:/Users/*removed*/uebungen/.git
21:38:08.604247 trace.c:378             setup: git_common_dir: C:/Users/*removed*/uebungen/.git
21:38:08.604247 trace.c:379             setup: worktree: C:/Users/*removed*
21:38:08.604247 trace.c:380             setup: cwd: C:/Users/*removed*
21:38:08.604247 trace.c:381             setup: prefix: (null)
21:38:08.604247 git.c:440               trace: built-in: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 14672 on Leo-PC' --check-self-contained-and-connected
remote:
remote: Enumerating objects: 852, done.
(...)                                                                     remote: Counting objects: 100% (852/852), done.
(...)                                                                        remote: Compressing objects: 100% (373/373), done.
remote: Total 1208 (delta 508), reused 792 (delta 461)
Receiving objects: 100% (1208/1208), 6.24 MiB | 36.54 MiB/s, done.
Resolving deltas: 100% (680/680), done.
21:38:09.614724 run-command.c:663       trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs '--progress=Checking connectivity'
21:38:09.628565 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
21:38:09.630566 trace.c:377             setup: git_dir: C:/Users/*removed*/uebungen/.git
21:38:09.630566 trace.c:378             setup: git_common_dir: C:/Users/*removed*/uebungen/.git
21:38:09.630566 trace.c:379             setup: worktree: C:/Users/*removed*
21:38:09.630566 trace.c:380             setup: cwd: C:/Users/*removed*
21:38:09.630566 trace.c:381             setup: prefix: (null)
21:38:09.630566 git.c:440               trace: built-in: git rev-list --objects --stdin --not --all --quiet --alternate-refs '--progress=Checking connectivity'
21:38:09.639568 chdir-notify.c:65       setup: chdir from 'C:/Users/*removed*' to 'C:/Users/*removed*/uebungen'
21:38:09.639568 chdir-notify.c:40       setup: reparent packed-refs to 'C:/Users/*removed*/uebungen/.git/packed-refs'
21:38:09.639568 chdir-notify.c:40       setup: reparent files-backend $GIT_DIR to 'C:/Users/*removed*/uebungen/.git'
21:38:09.639568 chdir-notify.c:40       setup: reparent files-backend $GIT_COMMONDIR to 'C:/Users/*removed*/uebungen/.git'

Have you tried cloning it on [WSL](https://learn.microsoft.com/en-us/windows/wsl/about) ? — Saurabh P Bhandari, Dec 15 '19 at 16:08
You could try cloning using the [`--no-checkout`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---no-checkout) option, checkout all files except the one causing the problem — Saurabh P Bhandari, Dec 15 '19 at 16:14
Does this answer your question? [How to handle files committed to Git on Linux with invalid Windows filenames?](https://stackoverflow.com/questions/4365231/how-to-handle-files-committed-to-git-on-linux-with-invalid-windows-filenames) — Saurabh P Bhandari, Dec 15 '19 at 16:27
Sadly, it doesn’t, as this doesn’t explain why it works on one Windows machine but not the other. As I said, I can’t just rename the file, as it’s not mine and is part of somebody else’s assignment. — Leo Klaus, Dec 15 '19 at 16:29
You could turn on [Debugging](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables) in git to know what is actually happening behind the scenes. — Saurabh P Bhandari, Dec 15 '19 at 16:43
For ex: You can update the question with the outputs of ```set "GIT_TRACE=true" & set "GIT_TRACE_SETUP=true" & git clone ``` from both the devices — Saurabh P Bhandari, Dec 15 '19 at 16:51
Alright. I will do that. I won’t have access to my desktop until tomorrow but will post results using the laptop in about half an hour. — Leo Klaus, Dec 15 '19 at 16:58
In git-bash, you can run this ```GIT_TRACE=true GIT_TRACE_SETUP=true git clone ``` — Saurabh P Bhandari, Dec 15 '19 at 17:01
What version of git are you using on both the devices ? (on git-bash run ```git --version```) — Saurabh P Bhandari, Dec 17 '19 at 00:02
Can you confirm the device names of your Laptop and Desktop to be `Leo-PC` and `DESKTOP-QNIF5QA` respectively ? — Saurabh P Bhandari, Dec 17 '19 at 00:06
In `remote: Enumeration of objects`, the count for both the logs differ, make sure you are cloning with the same repo link on both the devices — Saurabh P Bhandari, Dec 17 '19 at 00:39
In your desktop, you are able to access this file which is causing the problem `Aufgabe4a.py` ? — Saurabh P Bhandari, Dec 17 '19 at 00:45
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/204377/discussion-between-saurabh-p-bhandari-and-leo-klaus). — Saurabh P Bhandari, Dec 17 '19 at 01:04

Saurabh P Bhandari · Answer 1 · 2020-01-09T17:28:42.937

See VonC's answer for update on the issue

There is an open issue on git-for-windows repository (for v2.24)

Git 2.24 breaks existing repositories: filename in tree entry contains backslash

The workaround as suggested by user carlescufi is to disable core.protectNTFS.

git config --global core.protectNTFS false

Quoting git docs here,

core.protectNTFS

If set to true, do not allow checkout of paths that would cause problems with the NTFS filesystem, e.g. conflict with 8.3 "short" names. Defaults to true on Windows, and false elsewhere.

VonC · Answer 2 · 2021-05-12T23:15:39.807

With Git 2.25 (Q1 2020), the issue should be resolved.
An earlier update to Git for Windows declared that a tree object is invalid if it has a path component with backslash in it, which was overly strict, which has been corrected.

The only protection the Windows users need is to prevent such path (or any path that their filesystem cannot check out) from entering the index.

See commit 224c7d7 (31 Dec 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit a578ef9, 06 Jan 2020)}

mingw: only test index entries for backslashes, not tree entries

^{Signed-off-by: Johannes Schindelin}

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/git issue 2435

(issue mentioned in Saurabh P Bhandari's answer)

With Git 2.32 (Q2 2021), cygwin pathname handling is also fixed, ans explains more on the origin of the issue.

See commit bccc37f (29 Apr 2021) by Adam Dinwoodie (me-and).
^{(Merged by Junio C Hamano -- gitster -- in commit bb2feec, 07 May 2021)}

cygwin: disallow backslashes in file names

^{Reported-by: RyotaK}
^{Helped-by: Johannes Schindelin}
^{Signed-off-by: Adam Dinwoodie}

The backslash character is not a valid part of a file name on Windows.
If, in Windows, Git attempts to write a file that has a backslash character in the filename, it will be incorrectly interpreted as a directory separator.

This caused CVE-2019-1354 in MinGW, as this behaviour can be manipulated to cause the checkout to write to files it ought not write to, such as adding code to the .git/hooks directory.
This was fixed by e1d911d ("mingw: disallow backslash characters in tree objects' file names", 2019-09-12, Git v2.25.0-rc0 -- merge listed in batch #5).
However, the vulnerability also exists in Cygwin: while Cygwin mostly provides a POSIX-like path system, it will still interpret a backslash as a directory separator.

To avoid this vulnerability, CVE-2021-29468, extend the previous fix to also apply to Cygwin.

As well as checking behaviour in the presence of paths containing backslashes, the existing test also checks behaviour in the presence of paths that differ only by the presence of a trailing ".".
MinGW follows normal Windows application behaviour and treats them as the same path, but Cygwin more closely emulates *nix systems (at the expense of compatibility with native Windows applications) and will create and distinguish between such paths.
Gate the relevant bit of that test accordingly.

score 1 · Accepted Answer · answered Dec 17 '19 at 13:02

1

I've fixed the problem (for now), by downgrading to Git for Windows 2.23.0. The problem persists on the newest version and is reproducable on my desktop.

answered Dec 17 '19 at 13:02

Leo Klaus

73
1
8

The issue is resolved in __v2.25__, have a look at VonC's [answer](https://stackoverflow.com/a/59654503/10155936) – Saurabh P Bhandari Jan 09 '20 at 17:34

Pycharm behaving strange with Git (Filename in tree entry contains backslash)

3 Answers3

`mingw`: only test index entries for backslashes, not tree entries

`cygwin`: disallow backslashes in file names

Linked

Pycharm behaving strange with Git (Filename in tree entry contains backslash)

3 Answers3

mingw: only test index entries for backslashes, not tree entries

cygwin: disallow backslashes in file names

Linked

`mingw`: only test index entries for backslashes, not tree entries

`cygwin`: disallow backslashes in file names