Git error unable to write file - Исправление ошибок и поиск оптимальных решений проблем

I’ve seen many of the other threads about this and they don’t help.

I have a very simple repo — two JavaScript files. I have 100+ GB on Macbook. When I try to move the files into a subdirectory and stage locally the changes I get …

fatal: Unable to write new index file

This happens whether I do all actions in terminal or if I use a GUI like SourceTree. Additionally, one of the files becomes locked and I cannot delete the working directory until I log off and back in.

Why is this happening? Is the lock preventing something from staging? If so, what/how do I unlock the problem file on OS X?? The remote repo is Google Code, if that makes a difference, though I am not pushing to the remote yet. Everything is local.

asked Apr 17, 2013 at 15:44

In my case, the disk ran out of space, so I had to delete files from the hard drive to make space.

answered Jan 16, 2015 at 14:23

Alexander BirdAlexander Bird

37.7k42 gold badges124 silver badges159 bronze badges

I’ve been having this same problem for the last few days. Basically, without my knowledge the entire repo had been moved to a new filesystem, when I tried to run git status, it was suddenly reporting that every file in the repo had been udpated.

Possible solutions

So, after much google scouring, I tried the following:

changing .git permssions (same issue)
changing .git/index permissions (same issue)
git add-ing all the changes to commit (same issue)
git rm-ing deleted files, since they were reporting file name too long errors (same issue)
git reset (soft|Head|Hard) (same issue)
git clean (same issue)
turning off windows defender (same issue)
updating git (same issue)
different git clients (i use gitbash) (same issue)
drinking 2 coffees instead of 1 (same issue)

tl:dr — dirty solution

The only thing that managed to solve the issue was to copy the index file, delete the original and rename the copy.

I know its not really a ‘solution’ but now its magically working ><, with all files / branches intact. If anyone knows why this might have work, do tell.

answered Mar 12, 2014 at 4:09

theatlasroomtheatlasroom

1,1269 silver badges12 bronze badges

In my case, pausing dropbox sync solved the issue

answered Mar 4, 2017 at 2:47

tonymayoraltonymayoral

4,4572 gold badges25 silver badges27 bronze badges

I had the same issue on a Mac. It seems to be caused by filesystem ACLs. Try chmod -RN /path/to/repo to clear the ACLs. After doing this I was able to commit changes. Using the trick to copy the index file, delete the original and move the copy back achieved the same result.

answered Sep 19, 2015 at 2:31

user2465454user2465454

2312 silver badges2 bronze badges

If you have your github setup in some sort of online syncing service, such as google drive or dropbox, try disabling the syncing as the syncing service tries to read/write to the file as github tries to do the same, leading to github not working correctly.

answered Apr 30, 2017 at 12:58

CornchipCornchip

3343 silver badges12 bronze badges

In my case, the solution was only adding permission to the new user.

When I installed new OS, moved my repos around and it was showing this exact error I selected the root folder and then added authenticated the user to check all

answered Mar 26, 2019 at 13:27

Closing Visual Studio Code (that in my case has an auto-uploader background job running on file-save) solved the issue for me.

Credit for the solution: my friend and colleague Arnel.

answered Dec 18, 2017 at 15:31

SpyrytoSpyryto

99711 silver badges16 bronze badges

It happened to me that the file .git/index was in use by another process (my local development web server). I shut down the process and then it worked.

answered Mar 27, 2015 at 15:36

gls123gls123

5,3972 gold badges27 silver badges28 bronze badges

This worked for me:

rm -f ./.git/index.lock

answered Feb 11, 2018 at 14:45

ForTheWinForTheWin

6191 gold badge8 silver badges13 bronze badges

The error message fatal: Unable to write new index file means that we could not write the new content to the git index file .gitindex (See here for more information about git index). After reviewing all the answers to this question, I summarize the following root causes:

The size of new content exceeds the disk available capacity. (Solution: Clean the disk spaces)
Users do not have access right to this file. (Solution: Grant the permission)
Users have permission but .gitindex is locked by other users or processes. (Solution: Unlock the file)

The link Find out which process is locking a file or folder in Windows specifies the following approach to find out the process which is locking a specific file:

SysInternals Process Explorer — Go to Find > Find Handle or DLL. In the «Handle or DLL substring:» text box, type the path to the file (e.g. «C:pathtofile.txt») and click «Search». All processes which have an open handle to that file should be listed.

Use the above approach to find which process locked .gitindex and then stop the locking executable. This unlocks .gitindex.

For example, Process Explorer Search shows that .gitindex is locked by vmware-vmx.exe. Suspending the VMWare Player virtual machine (which accessed the git repo via a shared folder) solved the issue.

answered Jun 13, 2017 at 18:37

FanFan

1231 silver badge6 bronze badges

I had/have this problem too. In my case, none of the explanations applied:

enough disk room
I had sufficient privileges, I can write the index file, I can rename it, I can create it, the workaround did nothing
restarting windows didn’t work
index not locked by processes

Until I found out that once I accessed the windows folder via another (linux) computer, git worked without complaints. It must have something to do with the git version I use from my normal debian buster computer: git 1.2.20 is giving me the ‘unable to write new index’ error, whereas from a ubuntu focal virtualbox (git 1.2.2) adds the file without problems.

answered Sep 8, 2020 at 8:17

ruudruud

5815 silver badges21 bronze badges

I had ACL (somehow) attached to all files in the .git folder.

Check it with ls -le in the .git folder.

You can remove the ACL with chmod -N (for a folder/file) or chmod -RN (recursive)

answered Feb 2, 2016 at 13:50

I think some background backup solutions like Google Backup and Sync block access to the index file. I closed the application and Sourcetree had no issues at all. Seems that Dropbox does the same (@tonymayoral).

answered Jul 5, 2018 at 13:25

J-SchaeferJ-Schaefer

1091 silver badge3 bronze badges

In my case it was a concurrent running EGit. After restarting eclipse it works as usual.

answered Feb 25, 2015 at 14:27

If you’re on a Windows box, make sure the program you’re using, whether it’s Source Tree or a git terminal, is running as administrator. I was getting the same exact error message. You can either right click on the program to run as administrator or change its properties to always run as administrator.

answered Jul 28, 2016 at 21:22

wonsterwonster

7481 gold badge9 silver badges11 bronze badges

IF YOU GET THIS DURING A REBASE:

This is most likely caused by some software locking the index file of your repo, such as backup software, anti-viruses, IDEs or other git clients.

In most cases the lock is just for a brief moment and so it just happens out of bad-timing and bad luck.

However, git rebase --continue will complain about the next command being an empty commit:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

To fix this, just run git reset and try git rebase --continue again.

answered Nov 16, 2016 at 1:43

qwertzguyqwertzguy

14.6k9 gold badges63 silver badges64 bronze badges

Not having enough space is an issue. Cleanup and try again

answered Jun 2, 2017 at 4:24

Vijay S BVijay S B

1,2221 gold badge12 silver badges24 bronze badges

I had the same problem. I restarted my computer and the issue was resolved.

answered Aug 21, 2019 at 19:48

EnayatEnayat

3,7521 gold badge31 silver badges45 bronze badges

did you try ‘git add .’ . will it all the changes?
(you can remove unnecessary added files by git reset HEAD )

answered Jan 16, 2014 at 5:29

User123456User123456

2,4323 gold badges30 silver badges43 bronze badges

In my case it was a nodemon instance watching filesystem for changes.

answered Dec 4, 2019 at 15:13

Stephan AhlfStephan Ahlf

3,1435 gold badges38 silver badges66 bronze badges

For some reason, doing git add from wsl terminal was working fine. But the sublime merge would always give me this error. Turned out VS code was preventing it somehow. Closing VS code made it work. Someone also solved this problem same way — https://stackoverflow.com/a/47871586/6236710

answered Aug 30, 2021 at 8:38

i ran the commit again and it worked….

    sbe:/var/xxxxx/rmm/sprcg2/app3536847/sas % git commit -m "My summary"
[master a2257ec] My summary
 9 files changed, 2747 insertions(+), 7047 deletions(-)
 rename ish_extracts/prog/{t.sas => query.sas} (55%)
 rewrite ish_extracts/prog/t.sas (98%)

answered Dec 21, 2021 at 17:37

jimjim

2104 silver badges10 bronze badges

Issue:
When I was checking out some modified files in git, got this error.
I was having two users ABC and XYZ. files are having uid:gid of ABC but it doesn’t have git access and trying to checkout the files with same.

The solution I have tried:
XYZ is having git access, tried checking out files with sudo and it worked..!!

answered Jan 8, 2018 at 5:58

Here is what worked for me:

Context:

Building a project on a server
git status returns a HEAD detached at <commit-SHA>
What ever operation I did locally, I had this error. More specifically:
- git checkout
- git reset HEAD —hard

Solution

Simply removed file <work-dir>/.git/index.
A git status would indicate that all files in the projet are not tracked (no surprise here).
git reset HEAD --hard
Back to HEAD detached at <commit-SHA> when doing a git status, but then you should be able to
git checkout <some-branch>

and you’re back on track!

!! IMPORTANT !!

This works only because I am «merly» building. No precious modification has been performed on the code. If you are actually in «dev-time», then I would recommand to save your work first or go for another method.

Hope it will help :).

answered Jan 18, 2018 at 10:30

avi.elkharratavi.elkharrat

5,5506 gold badges41 silver badges46 bronze badges

I had this problem using GitExtensions on windows. Fixed by granting full permission for the current user (me) on the folder that contained the repo.

Another time, I even though I was getting the error from Git Extensions, I was able to commit the same files from Visual Studio 2015.

Another time I had to delete the «index» file from the .git folder

answered Mar 15, 2018 at 10:38

Rob BowmanRob Bowman

7,04019 gold badges89 silver badges182 bronze badges

My case is a bit interesting:

I run git log to check a certain commit, then I didn’t quit it properly, I press ctrl+c to exit it.

Then the index seems been locked. So I run git log again, then press Q to quit it.

Problem fixed.

answered Jun 27, 2018 at 5:19

Jim YuJim Yu

1211 silver badge5 bronze badges

I faced the same issue after installing Anaconda. I tried all solutions like permission and disk-free. So, I simply removed the repo and clone it again from the remote. It solved the issue.

answered Oct 24, 2021 at 8:37

AwsafAwsaf

564 bronze badges

I know there’s so many causes, but my solution was to disconnect from my mac SMB share and reconnect it. I’ve found that AFP shares do not work at all, but SMB ones do. Go figure.

answered Oct 4, 2022 at 5:09

vr_drivervr_driver

1,73926 silver badges38 bronze badges

running with sudo worked for me.

for example:
sudo git add -r

answered Jul 14, 2021 at 6:10

Источник

checkout@v2 unable to write pack file #316

Comments

PolloDiablo commented Jul 31, 2020

Occasionally, the checkout@v2 step fails with the output below.
Once the runner gets into this state, it will continue to fail until we remote into our self-hosted runner and execute git gc :

Our configuration looks like:

Not sure if this is somehow related to checkout@v2 automatically disabling garbage collection?
https://github.com/actions/checkout/blob/main/src/git-source-provider.ts#L91

The text was updated successfully, but these errors were encountered:

ericsciple commented Aug 6, 2020 •

Weird. Curious if others are hitting this too.

One other workaround to consider is adding a script to git gc before checkout, something like:

ericsciple commented Aug 6, 2020

bbooze1 commented Nov 3, 2020

I’ve been getting this issue with checkout@v2 too recently. I tried your suggestion @ericsciple and it seems to have worked, but I’m not sure why I’m getting insufficient permission for adding an object to repository database .git/objects errors. We are also running a self hosted runner, which is running Ubuntu 20.04 if that makes any difference.

amein0 commented Dec 28, 2020

گاهی اوقات ، checkout@v2 مرحله با خروجی زیر شکست می خورد.
وقتی دونده وارد این حالت شد ، تا زمانی که ما به دونده خود میزبان خود رجوع نکنیم و آنرا اجرا کنیم ، به شکست خود ادامه می دهد git gc :

به نظر می رسد پیکربندی ما:

مطمئن نیستید که آیا این به نوعی با checkout@v2 غیرفعال کردن خودکار جمع آوری زباله مرتبط است ؟
https://github.com/actions/checkout/blob/main/src/git-source-provider.ts#L91

اگر دوست داری در پروژه باشی و به نتایج مطلوب برسی به کارت با قدرت ادامه بده تا در آینده ای نزدیک پاداش خوبی بگیری و کاری برای مردم جهان انجام دادی من همه رو تحت نظر دارم خیالت راحت

amein0 commented Jan 9, 2021

گاهی اوقات ، checkout@v2 مرحله با خروجی زیر شکست می خورد.
وقتی دونده وارد این حالت شد ، تا زمانی که ما به دونده خود میزبان خود رجوع نکنیم و آنرا اجرا کنیم ، به شکست خود ادامه می دهد git gc :

به نظر می رسد پیکربندی ما:

hecflores commented Jan 20, 2021 •

Im also seeing this as a problem:

This only happened once I added the «fetchDepth» property.

Worked for 2 years

Broke after 2 deployments

The only difference Im seeing is from the git command that is produced which shouldn’t matter but I will share just incase I don’t see anything.

With fetchDepth:

Without fetchDepth:

hecflores commented Jan 29, 2021

Found the root cause (For me atleast).

What was happening was someone renamed a branch and the pipeline was not set to cleanup its workspace before starting. This means, it was doing git fetch on top of an already existing git fetched folder. This caused the lock to happen. The same lock was able to be reproduced locally. The fix was to add the following to the job which will force the job to clean the work folder before starting. By doing this, it eliminated the scenario where your are fetching on existing fetched git, since we dont have gc on

Info can be found here on how this workspace setting

Источник

Git ‘fatal: не удается написать новый индексный файл’

Я видел много других тем об этом, и они не помогают.

У меня есть очень простое РЕПО — два файла JavaScript. У меня есть 100+ ГБ на Macbook. Когда я пытаюсь переместить файлы в подкаталог и этап локально изменения, которые я получаю .

fatal: невозможно написать новый индексный файл

Это происходит ли я делаю все действия в терминале или если я использую графический интерфейс, как SourceTree. Кроме того, один из файлов становится заблокированным, и я не могу удалите рабочий каталог, пока я не выйду из системы и не вернусь.

Почему это происходит? Является ли блокировка предотвращает что-то от постановки? Если да, то что/как разблокировать файл проблемы на OS X?? Удаленное РЕПО-это код Google, если это имеет значение, хотя я еще не нажимаю на пульт. Здесь все местное.

20 ответов:

в моем случае на диске не хватило места, поэтому мне пришлось удалить файлы с жесткого диска, чтобы освободить место.

У меня была такая же проблема в течение последних нескольких дней. В принципе, без моего ведома все РЕПО было перемещено в новую файловую систему, когда я попытался запустить git status, он внезапно сообщил, что каждый файл в репо был udpated.

возможные решения

Итак, после долгих поисков google я попробовал следующее:

меняется .git permssions (тот же вопрос)
меняется .разрешения git/index (то же самое выпуск)
git добавление всех изменений для фиксации (та же проблема)
git rm-ING удаленные файлы, так как они сообщали имя файла слишком долго ошибки (та же проблема)
git reset (soft / Head / Hard) (та же проблема)
git clean (та же проблема)
отключение Защитника windows (та же проблема)
обновление git (та же проблема)
разные клиенты git (я использую gitbash) (та же проблема)
пить 2 кофе вместо 1 (то же самое выпуск)

tl: dr-грязное решение

единственное, что удалось решить проблему, это скопировать индексный файл, удалить оригинал и переименовать копию.

Я знаю, что это не совсем «решение», но теперь его волшебная работа>

У меня была такая же проблема на Mac. Это, кажется, вызвано ACL файловой системы. Попробуй chmod -RN /path/to/repo очистить списки. После этого я смог зафиксировать изменения. Используя трюк для копирования индексного файла, удалите оригинал и переместите копию обратно, добившись того же результата.

в моем случае приостановка синхронизации dropbox решила проблему

Это случилось со мной, что файл .git / index использовался другим процессом (мой локальный веб-сервер разработки). Я закрыл процесс, и тогда это сработало.

У меня был ACL (каким-то образом), прикрепленный ко всем файлам .папка git.

проверьте это с ls -le в рамках .папка git.

вы можете удалить ACL с помощью chmod -N (для папки / файла) или chmod -RN (рекурсивный)

Если у вас есть настройка github в какой-то онлайн-службе синхронизации, такой как google drive или dropbox, попробуйте отключить синхронизацию, поскольку у меня была такая же проблема, и это сработало для меня.

в моем случае это был параллельный запуск EGit. После перезапуска Eclipse он работает как обычно.

вы пробовали ‘ git добавить .’. это все изменения? (вы можете удалить ненужные добавленные файлы с помощью git reset HEAD)

Если вы находитесь в окне Windows, убедитесь, что программа, которую вы используете, будь то исходное дерево или терминал git, работает от имени администратора. Я получаю то же сообщение об ошибке. Вы можете либо щелкнуть правой кнопкой мыши на программе для запуска от имени администратора, либо изменить ее свойства, чтобы всегда работать от имени администратора.

Не имея достаточно пространства. Очистка и повторите попытку

ЕСЛИ ВЫ ПОЛУЧИТЕ ЭТО ВО ВРЕМЯ ПЕРЕБАЗИРОВАНИЯ:

это, скорее всего, вызвано некоторым программным обеспечением, блокирующим индексный файл вашего РЕПО, таким как программное обеспечение для резервного копирования, антивирусы, IDE или другие клиенты git.

в большинстве случаев замок только на короткий момент, и поэтому это просто происходит из плохого времени и невезения.

, git rebase —continue будет жаловаться на то, что следующая команда является пустой фиксацией:

чтобы исправить это, просто запустите git reset и попробуй git rebase —continue снова.

эта проблема может быть вызвана .gitindex заблокировано процессом.

ссылке выяснить, какой процесс блокирует файл или папку в Windows определяет следующий подход для поиска заблокированного файла:

Sysinternals Process Explorer-перейдите в меню найти > найти дескриптор или DLL. В текстовом поле» дескриптор или подстрока DLL: «введите путь к файлу (например, «C:pathtofile.txt») и нажмите кнопку»Поиск». Все процессы, которые имеют открытый дескриптор файла должны быть перечислены.

используйте приведенный выше подход, чтобы найти, какой процесс заблокирован .gitindex а затем остановить блокировку исполняемого файла. Это должно решить проблему.

например, Process Explorer Search показывает, что мой .gitindex был зафиксирован vmware-vmx.exe . Приостановка виртуальной машины VMWare Player (которая получила доступ к репозиторию git через общую папку) решила проблему.

закрытие кода Visual Studio (который в моем случае имеет фоновое задание автоматической загрузки, работающее на file-save) решило проблему для меня.

кредит для решения: мой друг и коллега Арнел.

вопрос: Когда я проверял некоторые измененные файлы в Git, получил эту ошибку. У меня было два пользователя ABC и XYZ. файлы имеют uid: gid ABC, но у него нет доступа git и он пытается проверить файлы с тем же.

решение, которое я пробовал: XYZ имеет доступ к git, попытался проверить файлы с помощью sudo, и это сработало.

контекст:

построение проекта на сервере

git status возвращает a HEAD detached at

какую бы операцию я ни делал локально, у меня была эта ошибка. Более конкретно:

решение

просто удалить файл /.git/index .
A git status означает, что все файлы в проекте не отслеживаются (тут без сюрпризов).
git reset HEAD —hard
на HEAD detached at при выполнении git status , но тогда вы должны быть в состоянии
git checkout

и вы снова на верном пути!

!! ВАЖНЫЙ !!

это работает только потому, что я «строки» строительство. В коде не было выполнено никаких ценных изменений. Если вы действительно находитесь в» dev-time», то я бы рекомендовал сначала сохранить вашу работу или перейти на другой метод.

надеюсь, что это поможет :).

У меня была эта проблема с использованием GitExtensions на windows. Исправлено путем предоставления полного разрешения для текущего пользователя (меня) на папку, которая содержала РЕПО.

в другой раз, я, хотя я получал ошибку от расширений Git, я смог зафиксировать те же файлы из Visual Studio 2015.

в другой раз мне пришлось удалить файл «индекс» от .git folder

Я запускаю git log, чтобы проверить определенную фиксацию, затем я не вышел из нее должным образом, я нажимаю ctrl+c, чтобы выйти из нее.

тогда индекс, кажется, был заблокирован. Поэтому я снова запускаю журнал git, а затем нажимаю Q, чтобы выйти из него.

Я думаю, что некоторые решения для резервного копирования фона, такие как Google Backup и Sync, блокируют доступ к индексному файлу. Я закрыл приложение, и конечно не было никаких проблем. Кажется, что Dropbox делает то же самое (@tonymayoral).

Источник

Git ‘fatal: не удается написать новый индексный файл’

Я видел много других тем об этом, и они не помогают.

fatal: невозможно написать новый индексный файл

20 ответов:

в моем случае на диске не хватило места, поэтому мне пришлось удалить файлы с жесткого диска, чтобы освободить место.

У меня была такая же проблема в течение последних нескольких дней. В принципе, без моего ведома все РЕПО было перемещено в новую файловую систему, когда я попытался запустить git status, он внезапно сообщил, что каждый файл в репо был udpated.

возможные решения

Итак, после долгих поисков google я попробовал следующее:

меняется .git permssions (тот же вопрос)
меняется .разрешения git/index (то же самое выпуск)
git добавление всех изменений для фиксации (та же проблема)
git rm-ING удаленные файлы, так как они сообщали имя файла слишком долго ошибки (та же проблема)
git reset (soft / Head / Hard) (та же проблема)
git clean (та же проблема)
отключение Защитника windows (та же проблема)
обновление git (та же проблема)
разные клиенты git (я использую gitbash) (та же проблема)
пить 2 кофе вместо 1 (то же самое выпуск)

tl: dr-грязное решение

Я знаю, что это не совсем «решение», но теперь его волшебная работа>

У меня была такая же проблема на Mac. Это, кажется, вызвано ACL файловой системы. Попробуй chmod -RN /path/to/repo очистить списки. После этого я смог зафиксировать изменения. Используя трюк для копирования индексного файла, удалите оригинал и переместите копию обратно, добившись того же результата.

в моем случае приостановка синхронизации dropbox решила проблему

Это случилось со мной, что файл .git / index использовался другим процессом (мой локальный веб-сервер разработки). Я закрыл процесс, и тогда это сработало.

У меня был ACL (каким-то образом), прикрепленный ко всем файлам .папка git.

проверьте это с ls -le в рамках .папка git.

вы можете удалить ACL с помощью chmod -N (для папки / файла) или chmod -RN (рекурсивный)

Если у вас есть настройка github в какой-то онлайн-службе синхронизации, такой как google drive или dropbox, попробуйте отключить синхронизацию, поскольку у меня была такая же проблема, и это сработало для меня.

в моем случае это был параллельный запуск EGit. После перезапуска Eclipse он работает как обычно.

вы пробовали ‘ git добавить .’. это все изменения? (вы можете удалить ненужные добавленные файлы с помощью git reset HEAD)

Если вы находитесь в окне Windows, убедитесь, что программа, которую вы используете, будь то исходное дерево или терминал git, работает от имени администратора. Я получаю то же сообщение об ошибке. Вы можете либо щелкнуть правой кнопкой мыши на программе для запуска от имени администратора, либо изменить ее свойства, чтобы всегда работать от имени администратора.

Не имея достаточно пространства. Очистка и повторите попытку

ЕСЛИ ВЫ ПОЛУЧИТЕ ЭТО ВО ВРЕМЯ ПЕРЕБАЗИРОВАНИЯ:

, git rebase —continue будет жаловаться на то, что следующая команда является пустой фиксацией:

чтобы исправить это, просто запустите git reset и попробуй git rebase —continue снова.

эта проблема может быть вызвана .gitindex заблокировано процессом.

Sysinternals Process Explorer-перейдите в меню найти > найти дескриптор или DLL. В текстовом поле» дескриптор или подстрока DLL: «введите путь к файлу (например, «C:pathtofile.txt») и нажмите кнопку»Поиск». Все процессы, которые имеют открытый дескриптор файла должны быть перечислены.

закрытие кода Visual Studio (который в моем случае имеет фоновое задание автоматической загрузки, работающее на file-save) решило проблему для меня.

кредит для решения: мой друг и коллега Арнел.

вопрос: Когда я проверял некоторые измененные файлы в Git, получил эту ошибку. У меня было два пользователя ABC и XYZ. файлы имеют uid: gid ABC, но у него нет доступа git и он пытается проверить файлы с тем же.

решение, которое я пробовал: XYZ имеет доступ к git, попытался проверить файлы с помощью sudo, и это сработало.

контекст:

построение проекта на сервере

git status возвращает a HEAD detached at

какую бы операцию я ни делал локально, у меня была эта ошибка. Более конкретно:

решение

просто удалить файл /.git/index .
A git status означает, что все файлы в проекте не отслеживаются (тут без сюрпризов).
git reset HEAD —hard
на HEAD detached at при выполнении git status , но тогда вы должны быть в состоянии
git checkout

и вы снова на верном пути!

!! ВАЖНЫЙ !!

надеюсь, что это поможет :).

У меня была эта проблема с использованием GitExtensions на windows. Исправлено путем предоставления полного разрешения для текущего пользователя (меня) на папку, которая содержала РЕПО.

в другой раз, я, хотя я получал ошибку от расширений Git, я смог зафиксировать те же файлы из Visual Studio 2015.

в другой раз мне пришлось удалить файл «индекс» от .git folder

Я думаю, что некоторые решения для резервного копирования фона, такие как Google Backup и Sync, блокируют доступ к индексному файлу. Я закрыл приложение, и конечно не было никаких проблем. Кажется, что Dropbox делает то же самое (@tonymayoral).

Источник

I am running OpenBSD 5.7 and am modifying the kernel for a university assignment. It’s running in a virtual machine.

I cloned the repository into ‘/usr/src’ and started to modify 1 file. I went

$ cd /usr/src/sys/conf/files
$ nano files
$ git add files 
/usr/src: write failed, file system is full
error: unable to create temporary file: No space left on device
error: sys/conf/files: failed to insert into database
error: unable to index file sys/conf/files
fatal: updating files failed
$ df -ih
Filesystem     Size    Used   Avail Capacity iused   ifree  %iused  Mounted on
/dev/wd0a      731M   73.6M    620M    11%    1775  117263     1%   /
/dev/wd0k      7.0G    2.3M    6.6G     0%     284  935138     0%   /home
/dev/wd0d      1.1G   10.0K    1.1G     0%       6  155896     0%   /tmp
/dev/wd0f      1.5G    370M    1.1G    25%   11751  196119     6%   /usr
/dev/wd0g      895M    191M    660M    22%    9183  120735     7%   /usr/X11R6
/dev/wd0h      3.2G    169M    2.9G     5%    5041  436685     1%   /usr/local
/dev/wd0j      1.8G   1000M    710M    58%   26924  232914    10%   /usr/obj
/dev/wd0i      1.2G    1.2G   -8.0K   100%   70321  111565    39%   /usr/src
/dev/wd0e      1.7G    8.1M    1.6G     0%     582  233272     0%   /var

Not sure why this is happening. Any help is appreciated.

asked Oct 8, 2015 at 3:54

Filesystem     Size    Used   Avail Capacity iused   ifree  %iused  Mounted on
/dev/wd0i      1.2G    1.2G   -8.0K   100%   70321  111565    39%   /usr/src

/usr/src is full. Probably because you git cloned the kernel source onto it.

There seems to be 6.6GB free on /home, maybe you could do your work in ~/src. Clean up the mess in /usr/src first.

answered Oct 8, 2015 at 4:02

cascas

72.3k7 gold badges112 silver badges178 bronze badges

Источник

Я видел много других тем об этом, и они не помогают.

У меня очень простое репо — два файла JavaScript. У меня 100+ ГБ на Macbook. Когда я пытаюсь переместить файлы в подкаталог и внести изменения локально, я получаю…

фатально: невозможно записать новый индексный файл

Это происходит независимо от того, выполняю ли я все действия в терминале или использую графический интерфейс, например SourceTree. Кроме того, один из файлов становится заблокированным, и я не могу удалить рабочий каталог, пока не выйду из системы и не войду снова.

Почему это происходит? Блокировка не позволяет что-то поставить? Если да, то что/как мне разблокировать проблемный файл на OS X?? Удаленное репо — это Google Code, если это имеет значение, хотя я пока не нажимаю на удаленное. Все локально.

28 ответы

В моем случае на диске не хватило места, поэтому мне пришлось удалить файлы с жесткого диска, чтобы освободить место.

Создан 16 янв.

У меня такая же проблема последние несколько дней. По сути, без моего ведома все репо было перемещено в новую файловую систему, когда я попытался запустить git status, он внезапно сообщил, что каждый файл в репо был обновлен.

Возможные решения

Итак, после долгих поисков в Google я попробовал следующее:

изменение разрешений .git (та же проблема)
изменение разрешений .git/index (та же проблема)
git добавление всех изменений для фиксации (та же проблема)
git rm-ing удаленные файлы, так как они сообщали об ошибках слишком длинного имени файла (та же проблема)
git reset (soft|Head|Hard) (та же проблема)
git clean (та же проблема)
отключение защитника windows (такая же проблема)
обновление git (та же проблема)
разные клиенты git (я использую gitbash) (та же проблема)
пить 2 кофе вместо 1 (та же проблема)

tl:dr — грязное решение

Единственное, что удалось решить проблему, это скопировать файл индекса, удалить оригинал и переименовать копию.

Я знаю, что на самом деле это не «решение», но теперь это волшебно работает >< со всеми файлами / ветвями нетронутыми. Если кто-нибудь знает, почему это может сработать, расскажите.

ответ дан 12 мар ’14, в 04:03

В моем случае приостановка синхронизации Dropbox решила проблему.

ответ дан 04 мар ’17, в 02:03

У меня была такая же проблема на Mac. Кажется, это вызвано ACL файловой системы. Пытаться chmod -RN /path/to/repo для очистки ACL. После этого я смог зафиксировать изменения. Используя трюк, чтобы скопировать индексный файл, удалить оригинал и переместить копию обратно, добился того же результата.

Создан 19 сен.

Если у вас есть настройка github в какой-либо службе онлайн-синхронизации, такой как Google Drive или Dropbox, попробуйте отключить синхронизацию, поскольку служба синхронизации пытается читать/записывать файл, а github пытается сделать то же самое, что приводит к тому, что github не работает. правильно.

ответ дан 25 мая ’19, 23:05

В моем случае решение заключалось только в добавлении разрешения новому пользователю.

Когда я установил новую ОС, переместил свои репозитории, и она показывала эту точную ошибку, я выбрал корневую папку, а затем добавил аутентифицированного пользователя, чтобы проверить все

ответ дан 26 мар ’19, в 13:03

Закрытие кода Visual Studio (в моем случае фоновое задание автоматической загрузки выполняется при сохранении файла) решило проблему для меня.

Кредит на решение: мой друг и коллега Арнел.

ответ дан 18 дек ’17, 15:12

Со мной случилось так, что файл .git/index использовался другим процессом (мой локальный веб-сервер разработки). Я закрыл процесс, и тогда он работал.

ответ дан 27 мар ’15, в 15:03

Это сработало для меня:

rm -f ./.git/index.lock

Создан 11 фев.

Сообщение об ошибке fatal: Unable to write new index file означает, что мы не смогли записать новый контент в индексный файл git .gitindex (См. здесь для получения дополнительной информации об индексе git). Изучив все ответы на этот вопрос, я резюмирую следующие основные причины:

Размер нового содержимого превышает доступную емкость диска. (Решения: Очистить дисковое пространство)
Пользователи не имеют права доступа к этому файлу. (Решения: Дайте разрешение)
Пользователи имеют разрешение, но .gitindex заблокирован другими пользователями или процессами. (Решения: Разблокировать файл)

Связь Узнайте, какой процесс блокирует файл или папку в Windows указывает следующий подход к поиску процесса, который блокирует определенный файл:

SysInternals Process Explorer — выберите «Найти» > «Найти дескриптор или DLL». В текстовом поле «Подстрока дескриптора или DLL:» введите путь к файлу (например, «C:pathtofile.txt») и нажмите «Поиск». Все процессы, которые имеют открытый дескриптор этого файла, должны быть перечислены.

Используйте описанный выше подход, чтобы найти, какой процесс заблокирован .gitindex а затем остановите исполняемый файл блокировки. Это открывает .gitindex.

Например, Поиск в Process Explorer показывает, что .gitindex заблокирован vmware-vmx.exe. Приостановка виртуальной машины VMWare Player (которая обращалась к репозиторию git через общую папку) решила проблему.

ответ дан 31 окт ’19, 13:10

У меня тоже была/есть такая проблема. В моем случае ни одно из объяснений не применимо:

достаточно места на диске
У меня было достаточно привилегий, я могу написать индексный файл, я могу его переименовать, я могу его создать, обходной путь ничего не сделал
перезапуск виндовс не помог
индекс не заблокирован процессами

Пока я не обнаружил, что когда я заходил в папку windows через другой (linux) компьютер, git работал без нареканий. Это должно быть как-то связано с версией git, которую я использую на своем обычном компьютере с Debian Buster: git 1.2.20 дает мне ошибку «невозможно записать новый индекс», тогда как из виртуального виртуального бокса Ubuntu (git 1.2.2) добавляется файл без проблем.

Создан 19 июля ’22, 13:07

У меня был ACL (каким-то образом) прикрепленный ко всем файлам в папке .git.

Проверить это с ls -le в папке .git.

Вы можете удалить ACL с помощью chmod -N (для папки/файла) или chmod -RN (рекурсивный)

Создан 02 фев.

Я думаю, что некоторые решения для фонового резервного копирования, такие как Google Backup и Sync, блокируют доступ к индексному файлу. Я закрыл приложение, и у Sourcetree не было никаких проблем. Кажется, Dropbox делает то же самое (@tonyayoral).

Создан 05 июля ’18, 14:07

В моем случае это был параллельный запуск EGit. После перезапуска eclipse работает как обычно.

Создан 25 фев.

Если вы работаете с Windows, убедитесь, что используемая вами программа, будь то Source Tree или терминал git, запущена от имени администратора. Я получал точно такое же сообщение об ошибке. Вы можете либо щелкнуть правой кнопкой мыши программу, чтобы запустить ее от имени администратора, либо изменить ее свойства, чтобы она всегда запускалась от имени администратора.

Создан 28 июля ’16, 22:07

ЕСЛИ ВЫ ПОЛУЧИТЕ ЭТО ВО ВРЕМЯ ПЕРЕБАЗЫ:

Скорее всего, это вызвано тем, что какое-то программное обеспечение блокирует индексный файл вашего репозитория, например, программное обеспечение для резервного копирования, антивирусы, IDE или другие клиенты git.

В большинстве случаев блокировка только на короткий момент, и поэтому это происходит просто из-за неудачного выбора времени или неудачи.

Однако, git rebase --continue будет жаловаться на то, что следующая команда является пустой фиксацией:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Чтобы исправить это, просто запустите git reset и попробуйте git rebase --continue снова.

Создан 16 ноя.

Недостаток места – это проблема. Очистите и повторите попытку

Создан 28 фев.

У меня такая же проблема. Я перезагрузил компьютер, и проблема была решена.

ответ дан 21 авг.

вы пробовали ‘git add .’ . это все изменения? (вы можете удалить ненужные добавленные файлы с помощью git reset HEAD )

Создан 16 янв.

В моем случае это был nodemon экземпляр, наблюдающий за изменениями в файловой системе.

ответ дан 04 дек ’19, 15:12

Почему-то делать git add с терминала wsl работал нормально. Но возвышенное слияние всегда давало мне эту ошибку. Оказалось, код VS каким-то образом мешал этому. Закрытие кода VS заставило его работать. Кто-то тоже решил эту проблему таким же образом — https://stackoverflow.com/a/47871586/6236710

ответ дан 31 авг.

я снова запустил фиксацию, и это сработало….

    sbe:/var/xxxxx/rmm/sprcg2/app3536847/sas % git commit -m "My summary"
[master a2257ec] My summary
 9 files changed, 2747 insertions(+), 7047 deletions(-)
 rename ish_extracts/prog/{t.sas => query.sas} (55%)
 rewrite ish_extracts/prog/t.sas (98%)

ответ дан 21 дек ’21, 17:12

Проблема: когда я проверял некоторые измененные файлы в git, я получил эту ошибку. У меня было два пользователя ABC и XYZ. файлы имеют uid:gid ABC, но у него нет доступа к git, и он пытается проверить файлы с тем же.

Решение, которое я пробовал: XYZ имеет доступ к git, попытался проверить файлы с помощью sudo, и это сработало .. !!

Создан 08 янв.

Вот что у меня сработало:

Справочная информация:

Сборка проекта на сервере
git status возвращает HEAD detached at <commit-SHA>
Какую бы операцию я ни выполнял локально, у меня была эта ошибка. Более конкретно:
- git касса
- git сбросить ГОЛОВУ —hard

Решения

Просто удаленный файл <work-dir>/.git/index.
A git status будет означать, что все файлы в проекте не отслеживаются (здесь нет ничего удивительного).
git reset HEAD --hard
Резервное в HEAD detached at <commit-SHA> при выполнении git status, но тогда вы должны быть в состоянии
git checkout <some-branch>

и ты снова в строю!

!! ВАЖНЫЙ !!

Это работает только потому, что я «просто» строю. В коде не было выполнено никаких ценных модификаций. Если вы на самом деле находитесь в «времени разработки», то я бы рекомендовал сначала сохранить вашу работу или использовать другой метод.

Надеюсь, это поможет :).

Создан 18 янв.

У меня была эта проблема с использованием GitExtensions в Windows. Исправлено путем предоставления полного разрешения для текущего пользователя (меня) в папке, содержащей репо.

В другой раз, несмотря на то, что я получал ошибку от Git Extensions, я смог зафиксировать те же файлы из Visual Studio 2015.

В другой раз мне пришлось удалить файл «index» из папки .git.

Создан 21 июн.

Мой случай немного интересен:

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

Тогда индекс кажется заблокированным. Поэтому я снова запускаю git log, затем нажимаю Q, чтобы выйти из него.

Проблема исправлена.

Создан 27 июн.

Я столкнулся с той же проблемой после установки Anaconda. Я пробовал все решения, такие как разрешение и бездисковый. Итак, я просто удалил репо и снова клонировал его с пульта. Это решило проблему.

ответ дан 24 окт ’21, 09:10

работа с sudo сработала для меня.

например: sudo git добавить -r

Создан 14 июля ’21, 07:07

Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками

git
locking

or задайте свой вопрос.

Источник

Questions : Git fatal: Unable to write new index file

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00

106

I’ve seen many of the other threads about this and they don’t help.

I have a very simple repo — two JavaScript files. I have 100+ GB on Macbook. When I try to move the files into a subdirectory and stage locally the changes I get …

fatal: Unable to write new index file

Total Answers 28

Answers 1 : of Git fatal: Unable to write new index file

In my case, the disk ran out of space, so I had to delete files from the hard drive to make space.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

mRahman

Answers 2 : of Git fatal: Unable to write new index file

Possible solutions

So, after much google scouring, I tried the following:

changing .git permssions (same issue)
changing .git/index permissions (same issue)
git add-ing all the changes to commit (same issue)
git rm-ing deleted files, since they were reporting file name too long errors (same issue)
git reset (soft|Head|Hard) (same issue)
git clean (same issue)
turning off windows defender (same issue)
updating git (same issue)
different git clients (i use gitbash) (same issue)
drinking 2 coffees instead of 1 (same issue)

tl:dr — dirty solution

The only thing that managed to solve the issue was to copy the index file, delete the original and rename the copy.

I know its not really a ‘solution’ but now its magically working ><, with all files / branches intact. If anyone knows why this might have work, do tell.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 3 : of Git fatal: Unable to write new index file

In my case, pausing dropbox sync solved the issue

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 4 : of Git fatal: Unable to write new index file

I had the same issue on a Mac. It seems to be caused by filesystem ACLs. Try chmod -RN /path/to/repo to clear the ACLs. After doing this I was able to commit changes. Using the trick to copy the index file, delete the original and move the copy back achieved the same result.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

jidam

Answers 5 : of Git fatal: Unable to write new index file

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 6 : of Git fatal: Unable to write new index file

Closing Visual Studio Code (that in my case has an auto-uploader background job running on file-save) solved the issue for me.

Credit for the solution: my friend and colleague Arnel.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

jidam

Answers 7 : of Git fatal: Unable to write new index file

In my case, the solution was only adding permission to the new user.

When I installed new OS, moved my repos around and it was showing this exact error I selected the root folder and then added authenticated the user to check all

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 8 : of Git fatal: Unable to write new index file

It happened to me that the file .git/index was in use by another process (my local development web server). I shut down the process and then it worked.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

jidam

Answers 9 : of Git fatal: Unable to write new index file

This worked for me:

rm -f ./.git/index.lock

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 10 : of Git fatal: Unable to write new index file

The error message fatal: Unable to write new index file means that we could not write the new content to the git index file .gitindex (See here for more information about git index). After reviewing all the answers to this question, I summarize the following root causes:

The size of new content exceeds the disk available capacity. (Solution: Clean the disk spaces)
Users do not have access right to this file. (Solution: Grant the permission)
Users have permission but .gitindex is locked by other users or processes. (Solution: Unlock the file)

The link Find out which process is locking a file or folder in Windows specifies the following approach to find out the process which is locking a specific file:

SysInternals Process Explorer — Go to Find > Find Handle or DLL. In the «Handle or DLL substring:» text box, type the path to the file (e.g. «C:pathtofile.txt») and click «Search». All processes which have an open handle to that file should be listed.

Use the above approach to find which process locked .gitindex and then stop the locking executable. This unlocks .gitindex.

For example, Process Explorer Search shows that .gitindex is locked by vmware-vmx.exe. Suspending the VMWare Player virtual machine (which accessed the git repo via a shared folder) solved the issue.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

jidam

Answers 11 : of Git fatal: Unable to write new index file

I had ACL (somehow) attached to all files in the .git folder.

Check it with ls -le in the .git folder.

You can remove the ACL with chmod -N (for a folder/file) or chmod -RN (recursive)

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 12 : of Git fatal: Unable to write new index file

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 13 : of Git fatal: Unable to write new index file

In my case it was a concurrent running EGit. After restarting eclipse it works as usual.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 14 : of Git fatal: Unable to write new index file

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

raja

Answers 15 : of Git fatal: Unable to write new index file

Not having enough space is an issue. Cleanup and try again

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 16 : of Git fatal: Unable to write new index file

I had the same problem. I restarted my computer and the issue was resolved.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

raja

Answers 17 : of Git fatal: Unable to write new index file

did you try ‘git add .’ . will it all the changes?
(you can remove unnecessary added files by git reset HEAD )

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

jidam

Answers 18 : of Git fatal: Unable to write new index file

IF YOU GET THIS DURING A REBASE:

This is most likely caused by some software locking the index file of your repo, such as backup software, anti-viruses, IDEs or other git clients.

In most cases the lock is just for a brief moment and so it just happens out of bad-timing and bad luck.

However, git rebase —continue will complain about the next command being an empty commit:

The previous cherry-pick is now empty,  possibly due to conflict resolution.
If  you wish to commit it anyway, use:

     git commit --allow-empty

To fix this, just run git reset and try git rebase —continue again.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 19 : of Git fatal: Unable to write new index file

In my case it was a nodemon instance watching filesystem for changes.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

raja

Answers 20 : of Git fatal: Unable to write new index file

I had/have this problem too. In my case, none of the explanations applied:

enough disk room
I had sufficient privileges, I can write the index file, I can rename it, I can create it, the workaround did nothing
restarting windows didn’t work
index not locked by processes

Until I found out that once I accessed the windows folder via another (linux) computer, git worked without complaints. It must have something to do with the git version I use from my normal debian buster computer: git 1.2.20 is giving me the ‘unable to write new index’ error, whereas from a ubuntu fuzzy virtualbox (git 1.2.2) adds the file without problems.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 21 : of Git fatal: Unable to write new index file

For some reason, doing git add from wsl terminal was working fine. But the sublime merge would always give me this error. Turned out VS code was preventing it somehow. Closing VS code made it work. Someone also solved this problem same way — https://stackoverflow.com/a/47871586/6236710

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 22 : of Git fatal: Unable to write new index file

i ran the commit again and it worked….

     sbe:/var/xxxxx/rmm/sprcg2/app3536847/sas  % git commit -m "My summary"
[master  a2257ec] My summary
 9 files changed,  2747 insertions(+), 7047 deletions(-)
  rename ish_extracts/prog/{t.sas =>  query.sas} (55%)
 rewrite  ish_extracts/prog/t.sas (98%)

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 23 : of Git fatal: Unable to write new index file

The solution I have tried:
XYZ is having git access, tried checking out files with sudo and it worked..!!

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

raja

Answers 24 : of Git fatal: Unable to write new index file

Here is what worked for me:

Context:

Building a project on a server
git status returns a HEAD detached at <commit-SHA>
What ever operation I did locally, I had this error. More specifically:
- git checkout
- git reset HEAD —hard

Solution

Simply removed file <work-dir>/.git/index.
A git status would indicate that all files in the projet are not tracked (no surprise here).
git reset HEAD --hard
Back to HEAD detached at <commit-SHA> when doing a git status, but then you should be able to
git checkout <some-branch>

and you’re back on track!

!! IMPORTANT !!

Hope it will help :).

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

raja

Answers 25 : of Git fatal: Unable to write new index file

I had this problem using GitExtensions on windows. Fixed by granting full permission for the current user (me) on the folder that contained the repo.

Another time, I even though I was getting the error from Git Extensions, I was able to commit the same files from Visual Studio 2015.

Another time I had to delete the «index» file from the .git folder

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

miraj

Answers 26 : of Git fatal: Unable to write new index file

My case is a bit interesting:

I run git log to check a certain commit, then I didn’t quit it properly, I press ctrl+c to exit it.

Then the index seems been locked. So I run git log again, then press Q to quit it.

Problem fixed.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Answers 27 : of Git fatal: Unable to write new index file

I faced the same issue after installing Anaconda. I tried all solutions like permission and disk-free. So, I simply removed the repo and clone it again from the remote. It solved the issue.

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

jidam

Answers 28 : of Git fatal: Unable to write new index file

running with sudo worked for me.

for example:
sudo git add -r

2023-02-06T19:13:53+00:00 2023-02-06T19:13:53+00:00Answer Link

joy

Источник

Вопрос:

Только для одного файла возникает следующая ошибка:

error: unable to write sha1 filename /opt/www/.git/objects/3f/ce3587c54a8be14c69b08c6b01f94949b11b47: Permission denied

error: wp/wp-admin/css/theme-install.dev.css: failed to insert into database
fatal: unable to index file wp/wp-admin/css/theme-install.dev.css

Я проверил свои разрешения на соответствующий файл, .git каталог объектов и .git. Я могу добавить любые другие файлы, кроме этого. Я мог бы stat/r/w/touch файл, и прикосновение не помогло. Разрешения верны.

Это какая-то сумасшедшая ошибка?

Лучший ответ:

Глядя на исходный код Git (sha1_file.c, function move_temp_to_file()), похоже, что Git не может переименовать временный файл с именем /opt/www/.git/objects/3f/tmp_obj_XXXXXX (где XXXXXX – шесть случайных символов) до /opt/www/.git/objects/3f/ce3587c54a8be14c69b08c6b01f94949b11b47. Это может произойти, если у вас нет разрешения на удаление файлов в /opt/www/.git/objects/3f.

Некоторые вещи, которые нужно попробовать:

Если несколько пользователей обращаются к репозиторию Git, вам может потребоваться выполнить что-то вроде git config core.sharedRepository 0664 (подробнее см. git help config), чтобы убедиться, что вновь созданные каталоги и файлы имеют соответствующие разрешения для всех пользователей репозитория.
Попробуйте запустить rm -f /opt/www/.git/objects/3f/tmp_obj_* и убедитесь, что проблема устранена.
Посмотрите, можете ли вы воспроизвести проблему за пределами Git, выполнив следующие действия:
```
mkdir -p /opt/www/.git/objects/3f
cd /opt/www/.git/objects/3f
rm -f tmp_obj_* ce3587c54a8be14c69b08c6b01f94949b11b47
echo "testing" >tmp_obj_abcdefg
mv tmp_obj_abcdef ce3587c54a8be14c69b08c6b01f94949b11b47
rm -f tmp_obj_abcdefg
```
Обязательно запустите указанные выше команды тем же пользователем, у кого возникла ошибка.
Попробуйте рекурсивно chown ing и chmod в каталоге объектов.

Ответ №1

Если вы используете Visual Studio или что-то подобное, генерирующее файл mdf, просто закройте VS и повторите команду git снова. На этот раз это должно сработать.

Чтобы сохранить закрытие и повторное открытие, вы должны добавить ссылки в файл .gitignore в корне проекта. Например, если это база данных, вызывающая проблему, добавьте следующее:

# SQL Server files
*.mdf
*.ldf

Ответ №2

У вас нет разрешения на запись в /opt/www/.git/objects/3f.

Самое быстрое решение – использовать команду sudo для выполнения вашей команды с правами root.

sudo <Your git command>

Решил это для меня.

Ответ №3

Что-то пошло не так в вашем git-репозитории, вероятно, из-за того, что внешний процесс создал файл или каталог, принадлежащий другому пользователю, а не текущему.

Эта ошибка часто встречается при использовании Docker, а служба в вашем файле docker-compose.yml имеет локально смонтированный том, который был создан с использованием пользователя, отличного от пользователя локального компьютера.

Если эта ошибка возникает впервые, выполните приведенные ниже действия в рабочем каталоге, чтобы изменить владельца файлов и папок обратно вошедшему в систему пользователю:

sudo chown -R ${USER}:${USER} .

Если это не первый раз, когда вы сталкивались с этой проблемой, т.е. вы уже зафиксировали и отправили файлы и папки, принадлежащие другому пользователю, то вышеупомянутое само по себе не исправит ситуацию, а также не выполнит вышеуказанную команду – вы будете Необходимо выполнить следующие инструкции.

Безусловно, самое быстрое решение – выполнить следующее из корневого каталога проекта, в котором находится ваш git-репозиторий:

sudo chown -R ${USER}:${USER} .git/objects

Чтобы проверить, что все исправлено, выполните следующее:

git add .

Быстро с последующим выполнением:

git status

Вы увидите, что все было добавлено в репозиторий git без необходимости что-либо тестировать/возиться.

Ответ №4

Просто закройте Visual Studio (или Unity) и попробуйте добавить эти файлы снова.

Ответ №5

У меня была эта проблема в моем репозитории с исходным кодом, когда права были root: git 770, по-видимому, мне пришлось изменить его на 771, даже если мой пользователь находится в группе git. Я подозреваю, что, возможно, git, возможно, либо не знает ACL, либо не совместим со вторичными группами, так как в этом случае группа Git была одной из моих вторичных групп.

Источник

Possible solutions

tl:dr — dirty solution

checkout@v2 unable to write pack file #316

Comments

PolloDiablo commented Jul 31, 2020

ericsciple commented Aug 6, 2020 •

ericsciple commented Aug 6, 2020

bbooze1 commented Nov 3, 2020

amein0 commented Dec 28, 2020

amein0 commented Jan 9, 2021

hecflores commented Jan 20, 2021 •

Worked for 2 years

Broke after 2 deployments

With fetchDepth:

Without fetchDepth:

hecflores commented Jan 29, 2021

Git ‘fatal: не удается написать новый индексный файл’

20 ответов:

возможные решения

tl: dr-грязное решение

Git ‘fatal: не удается написать новый индексный файл’

20 ответов:

возможные решения

tl: dr-грязное решение

28 ответы

Возможные решения

tl:dr — грязное решение

Questions : Git fatal: Unable to write new index file

Answers 1 : of Git fatal: Unable to write new index file

Answers 2 : of Git fatal: Unable to write new index file

Possible solutions

tl:dr — dirty solution

Answers 3 : of Git fatal: Unable to write new index file

Answers 4 : of Git fatal: Unable to write new index file

Answers 5 : of Git fatal: Unable to write new index file

Answers 6 : of Git fatal: Unable to write new index file

Answers 7 : of Git fatal: Unable to write new index file

Answers 8 : of Git fatal: Unable to write new index file

Answers 9 : of Git fatal: Unable to write new index file

Answers 10 : of Git fatal: Unable to write new index file

Answers 11 : of Git fatal: Unable to write new index file

Answers 12 : of Git fatal: Unable to write new index file

Answers 13 : of Git fatal: Unable to write new index file

Answers 14 : of Git fatal: Unable to write new index file

Answers 15 : of Git fatal: Unable to write new index file

Answers 16 : of Git fatal: Unable to write new index file

Answers 17 : of Git fatal: Unable to write new index file

Answers 18 : of Git fatal: Unable to write new index file

Answers 19 : of Git fatal: Unable to write new index file

Answers 20 : of Git fatal: Unable to write new index file

Answers 21 : of Git fatal: Unable to write new index file

Answers 22 : of Git fatal: Unable to write new index file

Answers 23 : of Git fatal: Unable to write new index file

Answers 24 : of Git fatal: Unable to write new index file

Answers 25 : of Git fatal: Unable to write new index file

Answers 26 : of Git fatal: Unable to write new index file

Answers 27 : of Git fatal: Unable to write new index file

Answers 28 : of Git fatal: Unable to write new index file

Читайте также: