github/git Checkout Returns 'error: invalid path' on Windows

When I attempt to checkout a repository from github I get the error:

error: invalid path 'configs/perl-modules/DIST.64/perl-HTML-Tree-1:5.03-1.el6.noarch.rpm'

I suspect the issue is that the path contains a : which is illegal on Windows.

After researching the error, I've found 2 possible answers:
1) Change the path on the repository file. Unfortunately, this is is a team resource and can not be fixed in the foreseeable future.
2) Use sparse-checkout. I've tried this with no effect as evidenced in the following:

>$ git clone -n [email protected]:XXXXXX/deploy.git
Cloning into 'deploy'...
remote: Enumerating objects: 57, done.
remote: Counting objects: 100% (57/57), done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 86457 (delta 10), reused 22 (delta 8), pack-reused 86400
Receiving objects: 100% (86457/86457), 1.50 GiB | 4.73 MiB/s, done.
Resolving deltas: 100% (59779/59779), done.
$ cd deploy/
$ git config core.sparsecheckout true
$ echo www >> .git/info/sparse-checkout
$ git checkout centos6
error: invalid path 'configs/perl-modules/DIST.64/perl-HTML-Tree-1:5.03-1.el6.noarch.rpm'
error: invalid path 'configs/perlbrew/perls/perl-5.24.1/man/man3/App::Cpan.3'
.
. (repeat for many files)
.

This was done with Git for Windows "git version 2.28.0.windows.1". I have also tried both types of line endings and using various version of .git/info/sparse-checkout such as:

/*
!/configs/perl-modules
!/configs/perlbrew/perls/perl-5.24.1/man/man3

Checkout works fine on Linux, MacOS and WSL, only problem is that my IDEs don't work there. Why isn't sparse-checkout working on Windows. Is there any other possibilities?

After I opened an issue on the git-for-windows bug tracker (https://github.com/git-for-windows/git/issues/2803), I found that my issue had already been filed as https://github.com/git-for-windows/git/issues/2777. That issue suggested that I need to set another git flag:

git config core.protectNTFS false

This (#2777) indeed contains a bypass for the my problem. I hope the git or git-for-windows (who were very responsive) come up with a better warning message, or even a true fix like a filepath mapping scheme.

Note that this is only an issue when using sparse-checkout with windows.

I have experienced a similar problem, trying to checkout a repository from GitHub that contained files with a ":" in the name, on a Windows. (example file name that caused the problem: "test-img.jpg:Zone.Identifier"). The repo downloaded, but the files were not showing up in the folder.

I found that running git config core.protectNTFS false solved my issue, but only if I took some steps before and after running it. The entire process went like so:

1. Clone the Git repository locally;
2. 'cd' into the local Git repository folder that has just been cloned;
3. Run git reset
4. Run git config core.protectNTFS false
5. Run git checkout (just git checkout, no * at the end of command).

After that, I could see the files. Granted, some extra things downloaded from Git that are usually omitted, but it wasn't a big deal in my case.

In our case there was a filename aux.go and windows doesn't allow the creation of a file that has the word aux

Read more about this issue here

For those who want just the commands to workaround the issue:

git clone --sparse -c core.protectNTFS=false -n <repo-URL>
git sparse-checkout add "\!<pattern1>" "\!<pattern2>"
git checkout <branch>

Patterns are relative to repo root and can use *

> I suspect the issue is that the path contains [colon character] : which is illegal on Windows.

That is in fact the problem.

> [sparse checkout with] !configs/perlbrew/perls/perl-5.24.1/man/man3

The pathname being complained-about here is:

configs/perl-modules/DIST.64/perl-HTML-Tree-1:5.03-1.el6.noarch.rpm

which does not begin with configs/perlbrew/, much less the full to-be-skipped path.

You can probably work around this by (painfully) enumerating all the invalid file names. Git needs a better general mechanism for this, though.

Addendum - git version 2.34.1.windows.1 & others(?)

Regrettably, git config core.protectNTFS false turned out not to be enough; the contents of the colon-carrying filenames are lost (filesize = 0).

Solution

TL;DR

git diff ec28c8ddd5f8c83d11604bcae69afb46d79b1029 > p.patch
patch -R -f -i p.patch
git add *
git commit 

Elaboration

Turns out git config core.protectNTFS false does work, insofar as to not produce fatal errors on git checkout anymore.

However, git now will produce filenames clipped to the colon and with zero content.

E.g. Writing-Bops:-The-Bebop-Schema-Language.md (~9KB) --> Writing-Bops (0 KB)

To fix this, we need to get a copy of the original offending file(s)' content another way, so we can restore it.

> > ### Conditions / Assumptions > > - This assumes you cannot or will not use a sparse clone for some reason. > - Ditto on git apply-filter and other techniques to 'permanently rewrite' git history, f.e. when you are tracking a third-party git repo. > - You're running Windows, using NTFS storage, git-for-windows with bash as your shell and have a patch.exe available (patch --version should report something like "GNU patch 2.7.6") >

(In our case, we were messing about with a github wiki clone and ran into this issue of filenames containing colons. Of course, we wanted to fix this in place, without going the extra 'sparse clone' or WSL mile.)

Turns out we can get the missing content after we did

git config core.protectNTFS false
git checkout <hash>

by running patch. (BTW: TortoiseGit would hang forever if you tried to diff/compare these commits!)

Use this next command to get a patch file with all the missing changes. If you have multiple files with colons or other trouble, all the missing content will be listed in the patchfile: one patchfile to catch it all!

git diff ec28c8ddd5f8c83d11604bcae69afb46d79b1029 > p.patch
# ^^^^ reference the git hash with the offending original file(s)

Now that you have a patchfile, you can apply it to the current working directory: it must be applied in reverse (-R):

patch -R -f -i p.patch

If you forget -R, patch will ask (answer [y]es); if you do specify -R patch will yak even more, so -f (force) is in order to shut up patch and just do the job.

This should list one or more files being patched as a result, e.g.

$ patch -R -f -i p.patch
patching file Writing-Bops:-The-Bebop-Schema-Language.md

> Note the colon in that filename: turns out GNU patch on windows (at least v2.7.6) uses a Unicode homoglyph to simulate a colon in a filename. See also further below.

You now have the original content of the colon-ed files in your working directory and you're now ready to add these files to the git index and commit them as usual:

> Warning: you'll probably need to cleanup (delete) the empty clipped filenames produced by your earlier git checkout before proceeding!

> Note: if you don't like the homoglyphed filename patch -i assigned to the missing content, you can change it to anything you like before committing the result.

git add *
git commit 

Verifying results

When you did everything right, that last commit should list the colon-ed file as renamed as you did not change the content and git commit should thus have detected the "file rename action" as-is.

Extra: replacing colon with a homoglyph

I found several Unicode homoglyphs that look more or less like a colon, but are considered legal in NTFS filenames.

After a bit of experimentation, I decided on using ꞉ as I wanted to keep the github wiki page I was fiddling with intact as much as possible.

Generally, I would discard the colon entirely, or replace it with one or more hyphens, but in the case of wiki MarkDown pages, that decision can go the other way.

If none of the other solutions work, the problem might be the version of git. I used version 2.31.1 and the error was shown, but then I tried it with the 2.15 and it worked fine. But for me the error was with the git clone command.

If operating with different OS eg linux vs windows or Mac Os vs Windows. Check characters in the file path. In my case I saved items on my mac and committed, when pulling on my windows machines, file path error accured.

Windows states that

> A filename cannot contain any of the following characters: \ / : * ? " < > |

But mine contained "*" in the image names saved. So just commit new names which are valid for the different OS your team is using. Or frustrate yourself more by looking for work-arounds

Simple right.

before using git clone

execute this command:

git config --global core.protectNTFS false

I have been like you , your filename is incorrect or not reserved , just rename your file

For those having a similar error:
Personally, the problem was using " in a file name on Linux and trying to pull on a Windows 10 machine.

In my case the file name had an extra space at the end. On Windows this was causing an issue.

I was able to fix this issue by removing this space. As I was not able to clone the project on Windows, this change has been done directly on where our repository was (which is GitHub in our case).

In my case, the repo contains files with invalid characters in Windows, like [ or ].

I discovered one option that had not been mentioned. Use WSL to checkout the files.

I ran git clone in WSL/Bash instead of PowerShell/CMD. WSL handles fixing the filenames transparently, even though they are still stored on NTFS and I open them using VS Code for Windows. I was able to modify the files in Windows, and push my changes on Windows even.

Once I supplied a target path to the git command it stopped looking for c:/program files/git/src This failed: git log --pretty=email --patch-with-stat --reverse --full-index --binary -- /src/pathtofile

This works: git log --pretty=email --patch-with-stat --reverse --full-index --binary -- ./src/pathtofile

You might wanna check on file naming. Windows does not allow some characters at the end of the file name eg "?", ":". Delete / rename them well and try again. PS: spaces aren't allowed either.

In GitHub: Going to the Repo URL (https://github.com/UserNameHere/RepoNameHere), then Clicking "Code" > "Download ZIP" and then extracting the .zip file in Windows was successful for me (I had to skip invalid files)