Git: "ошибка: удаленная распаковка не удалась: eof до того, как заголовок пакета был полностью прочитан" (пока ничего не помогло)
Всем Привет :)
Я опубликовал этот вопрос на другом форуме, но никто не ответил на него до сих пор, поэтому я тоже собираюсь попытать счастья здесь. Надеюсь, вы, ребята, не возражаете.
Должен признаться, что в этот момент я начинаю впадать в отчаяние. Поскольку информации об этой ошибке не так уж много, и то, что мне удалось найти, не помогло. Я действительно понимаю, что это своего рода общая ошибка, которая не говорит, что не так, и во всех других случаях, которые я видел до сих пор, эта ошибка сопровождается каким-то другим более конкретным сообщением об ошибке. Но в моем случае это не так. Я буквально получаю:
$ git push --set-upstream origin master Enumerating objects: 14403, done. error: remote unpack failed: eof before pack header was fully read error: failed to push some refs to 'ivan@server.lan:~/Git-Remote/Storage/Books.git'
Так что любая помощь будет оценена по достоинству! :)
Я должен дать вам хороший контекст того, что я пытаюсь сделать и что я пытался исправить эту проблему, поэтому заранее прошу прощения за длинный пост.
Процедура резервного копирования.
Поэтому я использую git как стандартный способ управления версиями, так и в качестве утилиты резервного копирования. У меня есть локальный сервер git, который работает 24/7. На этом сервере есть два жестких диска по 8 ТБ. И локальная машина работает под управлением windows 10, и у меня установлен git-for-windows.
У меня есть несколько репозиториев двоичных данных, которые я никогда не изменяю, а только добавляю новые файлы. Это картинки, музыка, программные пакеты, фильмы и т. д... И размер этих репозиториев варьируется от 20 до 100 ГБ или больше. Из - за этого я думаю, что было бы расточительно, если бы каталог .git находился в самом РЕПО. В некоторых случаях это невозможно, так как на жестком диске локальной машины недостаточно места. Так что прежде чем я казню:
git init
в нужном каталоге я открываю cmd от имени администратора, иду в каталог soon-to-be-repo и набираю что-то вроде:
mklink /D .git //HOME-SERVER/Git-Local/Storage/Books
Таким образом, я создаю символическую ссылку на каталог на удаленном сервере с именем .git, поэтому, когда я набираю "git init", он заполняет удаленный каталог вместо локального, который он создал бы, если бы я не сделал символическую ссылку. Тогда как "добавить в Git" и "коммитов" привлекать сетевых операций. На их выполнение уходит несколько часов.
Все эти данные отправляются на жесткий диск емкостью 8 ТБ на сервере с именем "Git-Local". Затем я подключаюсь по ssh к серверу и иду на другой 8-ТБ диск с именем "Git-Remote", где создаю каталог с именем "Books.git" и внутри него набираю:
git init --bare
Затем возвращаюсь в РЕПО на локальную машину иду:
git remote add origin ivan@server.lan:~/Git-Remote/Storage/Books.git
И напоследок:
git push --set-upstream origin master
Вы поняли идею... Я проделывал эту процедуру много раз, и она сработала!
Only two repos failed to push to the remote so far with the above error message. As you can see this way I have three copies in three physical hard drives. One in the local machine and two in separate drives in the server. As you well know the .git can be cloned so it's a valid storage of data. So the repo in question "Books" has like ~30GB of pdf documents, *.doc, HTMLs, scanned books and technical videos and courses in a large somewhat messy folder structure. There are a lot of tiny > 1kB files and some large files that might be the issue. Also there might be files with long names, although I think I should get a warning if a long filename is preventing git from working.
Что я уже пробовал:
Я проделал эту процедуру несколько раз с нуля. Очистка каталогов the .git и Book.git, запускающая процесс с самого начала. Но это не помогло.
Я пытался
git fsck --full
но и это не помогло...
Еще раз спасибо за ваше терпение, читая мой пост! :) Надеюсь, я хорошо объяснил эту проблему. Если у вас есть еще какие-то вопросы, не стесняйтесь задавать их.
P.S. Для протокола, я знаю, что git не предназначен для такого использования, но мне нравится история фиксаций и прослеживаемость.