Git clone error invalid path

Summary

The Git cloning of repository succeeds on a Linux client but fails on a Windows client with an «invalid path» error. Windows OS reserves some filenames, hence a file name may be legal in Linux but illegal in Windows.

Environment

Windows

Diagnosis

$ git clone --progress --verbose ssh://git@mybb.com:7999/project/myrepo.git
Cloning into 'myrepo'...
remote: Enumerating objects: 825542, done.
remote: Counting objects: 100% (825542/825542), done.
remote: Compressing objects: 100% (239771/239771), done.
remote: Total 1414136 (delta 769602), reused 586108 (delta 585739), pack-reused 588594
Receiving objects: 100% (1414136/1414136), 13.91 GiB | 22.80 MiB/s, done.
Resolving deltas: 100% (1132339/1132339), done.
error: invalid path 'path/to/broken/file/con.h'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

Nothing appears to be wrong with the path. The issue is that the base name of the file is con which is a reserved name in Windows.

Cause

Windows reserves certain file names so trying to create a file that uses a reserved base name should fail.

Please refer to the Naming a file Windows documentation:

Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended

Solution

Depending on the filename, configuring Git to ignore NTFS naming may workaround the issue.

git config --global core.protectNTFS false

Turning off protectNTFS will stop Git from complaining about files that have a base name that is reserved but will not prevent an error if the filename is one of the reserved names.

The only workaround is to rename any offending file(s) at the source repository or via a non-Windows client.

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.

Fixing Invalid Git Paths on Windows

One of the fun things about working with Git on Windows is that you’re often at the mercy of the filesystem underneath you, and this crops up in some entertaining ways:

• even though NTFS supports running as a case sensitive filesystem, the Win32 subsystem does not support filenames that differ by case sensitivty only
• some characters are not permitted by Win32 subsystem APIs — and I refer back to this link regularly to remind myself of this.

Even in the age of running Linux on Windows, these compatibility issues are not going away any time soon, and taking a repository and running it on Windows can be problematic, so the rest of this post is about repairing these repositories so they are not tied to a particular filesystem.

Please note

• All of these operations are being run inside Git Bash that ships with Git for Windows — if you are trying to perform the same actions in a different shell they’re likely to fail.
• These instructions are tailored to one repository. You’ll need to adapt these based on the problem file paths you encounter in your situation.
• This repository has been fixed, so you probably won’t be able to replicate the same behaviour by running the exact same commands either.

The Scene — A Failing Clone

You might have stumbled upon an error like this when cloning down someone else’s repository:

So here is where Git is actually falling over:

Did you read the link above about valid file path characters? I’ll quote the relevant part here:

Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following:

The following reserved characters:

as a path in Windows, but we have a repository that has some existing content using this character. That’s what we need to fix here.

At this point you could look inside the newly created repository on disk and try to salvage things. I wouldn’t recommend this approach because of this error message further down.

The working tree is the files on disk associated with the current branch (either the default branch or whatever branch you wanted to initially checkout). And with that in an unknown state, there is only pain ahead. Let’s try a different way.

Part 1 — Fix The Problem Checkout

Because git clone fails I used this set of commands to emulate a clone operation:

This gets us to a usable repository state, but these problem files still need addressing:

I’m going to just remove those so I have something to work with:

Now we have no problems checking out this branch, but we did this by removing the problem paths from the repository. If we want to be able to access those files in the repository we have more work to do.

Part 2 — Put The Files Back

Git keeps a history of all the file contents for all commits in it’s .git folder, and we can explore this using various Git plumbing commands.

We can use git ls-tree to read the tree contents of a given hash and find the original contents of the files we just removed:

Git stores each commit as a tree, and a tree can contain blobs (the file contents) or other trees. Each entry in a tree also needs a mode (for representing permissions) and a path. If you squint at this, it’s not unlike a filesystem representation as a data structure.

The two problem file paths are under test-files so we’ll use the e2a3b7648b57746e68ced4f881f193df05a2341f hash from the previous command and run git ls-tree again:

Excellent, we can see the problem file paths and they correlate to two blobs 5020200c10e545c19002f4878c2b6686035f10b0 and 0680d8432628eb071aa2c643f11fe8984df6e972 . These identifiers can be used to find the file contents.

The next step is to read out the contents of those blobs and write them to new files. I’m going to also create the SavedData directory name again because I think that was the intent here and someone just used the wrong slash and got away with it.

Now we have two new files to commit:

I’m not worried about the line ending warning here, and I can confirm this is accurate once we’ve completed these steps.

Now we can commit these files to the new path:

Now we have a branch that can be cloned on Windows safely.

Part 3 — Verification

To confirm that line ending warning was a non-issue, I can run the same git ls-tree command from earlier and confirm the new blobs are unchanged:

The two files are at the expected new location but still have the old blob hash.

To confirm the clone has been fixed, I cloned down my fork and ask it to checkout this branch:

Now, you just need to merge this branch into the default branch and everyone will benefit from this change.

Источник

Bitbucket Support

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Work Management

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

«error: invalid path» during git clone to Windows client

Related content

Still need help?

The Atlassian Community is here for you.

Platform Notice: Cloud, Server, and Data Center — This article applies equally to all platforms .

Summary

The Git cloning of repository succeeds on a Linux client but fails on a Windows client with an «invalid path» error. Windows OS reserves some filenames, hence a file name may be legal in Linux but illegal in Windows.

Environment

Diagnosis

The error will manifest during the final checkout during a git clone/fetch. As an example we try to clone a repository that contains the con.h filename.

Nothing appears to be wrong with the path. The issue is that the base name of the file is con which is a reserved name in Windows.

Cause

Windows reserves certain file names so trying to create a file that uses a reserved base name should fail.

Please refer to the Naming a file Windows documentation:

Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended

Solution

Whilst this may workaround the issue, care should be taken as the default for a Windows client was set to core.protectNTFS=true to close a potential security issue CVE-2019-1353 as described here.

Depending on the filename, configuring Git to ignore NTFS naming may workaround the issue.

Turning off protectNTFS will stop Git from complaining about files that have a base name that is reserved but will not prevent an error if the filename is one of the reserved names.

The only workaround is to rename any offending file(s) at the source repository or via a non-Windows client.

Источник

Почему не получается склонировать репозиторий?

Наталкивает на мысль что проблема в правах доступа, если это так то мой вопрос.
Как дать это «разрешение»?

терминал я открываю пкм в директории и выбираю конему в выпадающем меню, вопрос про открытие с правами админа система не задаёт.

п.с. только поставил вин10 у меня один диск С и свобоных 142гб

• Вопрос задан более года назад
• 2248 просмотров

Простой 1 комментарий

У тебя клонирование проходит успешно, значит с доступом всё в порядке. Но Git не может распаковать ветку в рабочий каталог: unable to checkout working tree. И даже показывает на каком файле споткнулся.

Я подозреваю что проблема в нестандартном названии папки. Некорректно обрабатывается точка в конце.
Последняя точка в названии служит разделителем между именем и расширением, и может отбрасываться при создании папки если после точки ничего нет, т. е. расширение «пустое».

Проверил на Windows. Даже если создать вручную папку с точкой, Git просто не может зайти в неё.

Я вижу несколько путей выхода:
1) Переименовать папку в той операционке, где поддерживаются такие имена. Закоммитить. Отправить на гитхаб. На компе с Windows сделать pull и ветка уже нормально распакуется.
2) Средствами гитхаба переименовать каждый файл вместе с его полным путём, если их не так много. Закоммитить. И забрать изменения как в предыдущем варианте.
3) Скачать проект в виде ZIP и распаковать в рабочий каталог с помощью WinRAR. Он автоматически уберёт все лишние точки. Закоммитить изменения.

Единственный недостаток — мы не сможем распаковать предыдущие версии проекта, а такое может иногда понадобиться. Поэтому у меня родился четвёртый способ, он самый простой. Одна команда делает всё хорошо.
4) Переименовываем папку во всех коммитах репозитория используя пакет git-filter-repo

Я больше подозреваю, что путь кривой. пробелы, точки, русские буквы.
Может пушили с Линукс, а с винды такой путь не смог склонироваться.

Кстати, на Stackoverflow обсуждают слишком длинные имена.
Тоже можно проверить. русские буквы — в utf8 занимают больше байт, чем английские.
можно попробовать
git config —system core.longpaths true or edit gitconfig (от админа)
или попробовать склонить в папку ближе к корню диска.

Пробелы и русские буквы не проблема ни для Windows, ни для Git. Всё прекрасно работает даже и иероглифами и эмодзи. Разве что консольный Git не умеет корректно выводить такие названия в лог, но тем не менее всё корректно обрабатывает и коммитит.

А вот точку в конце имени Git совершенно не переваривает, как оказалось. Придётся это запомнить.
Думаю и с пробелами в конце тоже будет затык.

Источник

Почему не получается склонировать репозиторий?

Наталкивает на мысль что проблема в правах доступа, если это так то мой вопрос.
Как дать это «разрешение»?

терминал я открываю пкм в директории и выбираю конему в выпадающем меню, вопрос про открытие с правами админа система не задаёт.

п.с. только поставил вин10 у меня один диск С и свобоных 142гб

• Вопрос задан более года назад
• 2248 просмотров

Простой 1 комментарий

У тебя клонирование проходит успешно, значит с доступом всё в порядке. Но Git не может распаковать ветку в рабочий каталог: unable to checkout working tree. И даже показывает на каком файле споткнулся.

Я подозреваю что проблема в нестандартном названии папки. Некорректно обрабатывается точка в конце.
Последняя точка в названии служит разделителем между именем и расширением, и может отбрасываться при создании папки если после точки ничего нет, т. е. расширение «пустое».

Проверил на Windows. Даже если создать вручную папку с точкой, Git просто не может зайти в неё.

Я вижу несколько путей выхода:
1) Переименовать папку в той операционке, где поддерживаются такие имена. Закоммитить. Отправить на гитхаб. На компе с Windows сделать pull и ветка уже нормально распакуется.
2) Средствами гитхаба переименовать каждый файл вместе с его полным путём, если их не так много. Закоммитить. И забрать изменения как в предыдущем варианте.
3) Скачать проект в виде ZIP и распаковать в рабочий каталог с помощью WinRAR. Он автоматически уберёт все лишние точки. Закоммитить изменения.

Единственный недостаток — мы не сможем распаковать предыдущие версии проекта, а такое может иногда понадобиться. Поэтому у меня родился четвёртый способ, он самый простой. Одна команда делает всё хорошо.
4) Переименовываем папку во всех коммитах репозитория используя пакет git-filter-repo

Я больше подозреваю, что путь кривой. пробелы, точки, русские буквы.
Может пушили с Линукс, а с винды такой путь не смог склонироваться.

Кстати, на Stackoverflow обсуждают слишком длинные имена.
Тоже можно проверить. русские буквы — в utf8 занимают больше байт, чем английские.
можно попробовать
git config —system core.longpaths true or edit gitconfig (от админа)
или попробовать склонить в папку ближе к корню диска.

Пробелы и русские буквы не проблема ни для Windows, ни для Git. Всё прекрасно работает даже и иероглифами и эмодзи. Разве что консольный Git не умеет корректно выводить такие названия в лог, но тем не менее всё корректно обрабатывает и коммитит.

А вот точку в конце имени Git совершенно не переваривает, как оказалось. Придётся это запомнить.
Думаю и с пробелами в конце тоже будет затык.

Источник

github / git Checkout возвращает ошибку: неверный путь в Windows

Когда я пытаюсь проверить репозиторий из github, я получаю сообщение об ошибке:

Я подозреваю, что проблема в том, что путь содержит:, что недопустимо в Windows.

Изучив ошибку, я нашел 2 возможных ответа:
1) Измените путь к файлу репозитория. К сожалению, это командный ресурс и не может быть исправлен в обозримом будущем.
2) Используйте разреженное оформление заказа. Я пробовал это без эффекта, о чем свидетельствует следующее:

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

Это было сделано с помощью Git для Windows «git version 2.28.0.windows.1». Я также пробовал оба типа окончаний строк и использовал различные версии .git / info / sparse-checkout, например:

Checkout отлично работает в Linux, MacOS и WSL, проблема только в том, что мои IDE там не работают. Почему в Windows не работает sparse-checkout. Есть ли другие возможности?

Источник