Reputation: 5955

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?

Upvotes: 215

Answers (21)

Abraham Brookes

Reputation: 1998

In my case I had created a folder in vscode by deeply nesting when I created the folder name (ie right click > New file > Enter folder\name\nested\file.php) and I am using WSL on a windows machine, so I believe that instead of creating three nested folders, it created one folder with backslashes in the name. The solution was to recreate that folder structure to use forward slashes, which updated the git ref to that file to have forward slashes and I could then check out my branch on another machine.

Upvotes: 0

Osman Islyamov

Reputation: 31

I was also not being able to pull master or even clone the repo on new directory (for Window) with error: invalid path 'schema.graphql ' and it appears that Windows can not retrieve the blank space and was not an issue for other OS.

So git config core.protectNTFS false before pull fixed the issue.

Upvotes: 3

Tanvir Akon

Reputation: 21

I also had somewhat have issue and it seemed i had a whitespace after a folder name.

Here's what i did:

go to main repo in github. then click . . it will open entire repo almost in vscode (web).
you must have checked in terminal which folder is causing the problem. in (web) vscode , carefully rename the folder (remove all whitespace and etc).
dont forget to stage and push back to github to apply the changes. (you will have the git button in the side panel).

Upvotes: 0

Gerard Jaryczewski

Reputation: 1052

If this is a case of unavailable support for symbolic links, try to reinstall your Git for Windows with "Enable symbolic link" option enabled.

More details here: Git symbolic links in Windows

Upvotes: 0

Jesus is Lord

Reputation: 15399

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)

Upvotes: 5

Victor Ashioya

Reputation: 111

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.

Upvotes: 0

Giora

Reputation: 1

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

Upvotes: 0

Ger Hobbelt

Reputation: 1188

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.

Upvotes: 8

pseudosavant

Reputation: 7234

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.

Upvotes: 5

Shaokun

Reputation: 88

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

Upvotes: 0

edocollado

Reputation: 619

before using git clone

execute this command:

git config --global core.protectNTFS false

Upvotes: 4

Özgür TEZEL

Reputation: 51

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).

Upvotes: 3

sn0wmaid3n

Reputation: 1029

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:

Clone the Git repository locally;
'cd' into the local Git repository folder that has just been cloned;
Run git reset
Run git config core.protectNTFS false
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.

Upvotes: 102

Marshall Fungai

Reputation: 303

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.

Upvotes: 1

Roman Orekhov

Reputation: 412

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 *

Upvotes: 13

wdtj

Reputation: 5955

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.

Upvotes: 321