Git Предупреждение о доставке: невозможно отключить файлы, разрешено

Мне известно, что в git есть похожие проблемы, связанные с предупреждением "невозможно отсоединить", но я не смог их использовать.

Основное отличие состоит в том, что это произошло, когда я никоим образом не имел дело с подмодулями (я никогда не имел дело с ними раньше). Я создал ветку с названием "upgrade", удалил мои старые файлы фреймворка и скопировал в новые. Я использовал git add -A, затем совершил все. Когда я попытался оформить ствол, он ответил следующими ошибками:

warning: unable to unlink requirements/views/sk/index.php: Permission denied
warning: unable to unlink requirements/views/sv/index.php: Permission denied
warning: unable to unlink requirements/views/zh/index.php: Permission denied
warning: unable to unlink requirements/views/zh_cn/index.php: Permission denied
warning: unable to unlink requirements/views/zh_tw/index.php: Permission denied

...так далее. Их сотни.

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

Изменение: как предложено в ответе ниже, я попытался сделать то же самое, но со всем остальным закрытым. У меня не было больше удачи, чем раньше.

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

ОТВЕТЫ

Ответ 1

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

Убедитесь, что ничего не запущено, а затем повторите попытку.

Примечание: это также может быть связано с тем, как был установлен Git (в Windows UAC может генерировать проблему, если msysgit установлен в C:\Program или C:\Program Files, см. " Msysgit - sh.exe - fork: Permission denied" - Vista 64 bit "и комментарий 2 к выпуску 437)

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

Ответ 2

В моей первой встрече с этой ошибкой мой пользователь имел права "писать" в файл, но не в содержащую директорию. Проверьте разрешения каталога, содержащего файл.

Ответ 3

"Unlink" по существу означает "удалить файл" в этом случае.

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

Ответ 4

У меня возникла проблема с файлом default-settings.php в drupal 7. В этом случае я не смог удалить его или вернуть его точно так же, как сказал @rtconner. У меня не было приложения или чего-либо, использующего этот файл, и он оказался ошибкой разрешений.

Я добавил chmod 777 * в папку, а затем я смог вернуться к ней без проблем.

Ответ 5

У вас нет доступа, возможно, потому, что вы не являетесь его владельцем.

Исправить, изменив владельца самостоятельно:

sudo chown -R your_login_name /path/to/folder

Ответ 6

Вы можете изменить права на запись, чтобы сделать это.

sudo chmod -R ug+w .

Эта команда предоставит разрешения 'w' для всех папок в текущем каталоге.

Ответ 7

Я столкнулся с этой проблемой при запуске "git repack" или "git gc" на моих машинах OS X даже при запуске git с правами администратора, и я, наконец, решил это после перехода на эту страницу: http://hints.macworld.com/comment.php?mode=view&cid=1734

Исправить это, чтобы открыть терминал, перейдите в свой git repo, cd в папку .git, а затем выполните:

chflags -R nouchg *

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

Ответ 8

Для тех, кто использует Intellij, поскольку @rtconner говорит, что эта проблема не вызвана git. Поскольку ваша среда IDE заблокирована, файл git не может его удалить. Таким образом, вам нужно закрыть свою среду IDE, а затем попытаться объединить (или что угодно) с помощью командной строки.

Ответ 9

Это также может произойти, если:

  • Вы выполнили процесс внутри контейнера Docker и:

  • Некоторые файлы были сгенерированы этим процессом и:

  • Назначение файлов монтируется в качестве тома на хосте Docker и:

  • Вы используете git на хосте Docker.

Если это так, выполните этап файлов, которые вы хотите зафиксировать и выполните:

git diff --name-only --cached | xargs ls -l

Файлы, соответствующие указанным выше критериям, будут иметь префикс:

-rw-r--r-- 1 root root ...

Они принадлежат root и не доступны для записи, что плохо. Чтобы исправить этот прогон:

 git diff --name-only --cached | xargs -i sh -c 'sudo chown $USER:$USER {}; chmod +w {}'

Более чистым решением, вероятно, будет использование опции --user, см. это для Docker и это для Docker составить.

Ответ 10

В моем случае это был символ ":" в имени папки, предваряющей репо git для проверки на окнах.

Ответ 11

У меня была эта ошибка внутри виртуальной машины (работает Ubuntu), когда я пытался сделать git reset --hard.

Исправление было просто для запуска git reset --hard с хост-машины OS X.

Ответ 12

на терминале на mac я просто делаю это

sudo git checkout. (очистить все)

а затем

sudo git pull origin

Ответ 13

Никакие другие предложения не работали для меня, но это делало:

sudo git reflog expire --expire=now --all && sudo git gc --prune=now --aggressive

Ответ 14

Я столкнулся с этой ошибкой и вызван неправильным "владельцем/группой" файла . Вы должны обратиться за помощью к администратору сервера, чтобы изменить "владелец/группу" этого файла/папки и повторить попытку с помощью "git pull". Или, если вы являетесь sudoer, просто sudo chown "имя вашего владельца/имя вашей группы" и попробуйте снова потянуть свой репозиторий. Попробуйте, он работает на 100% для меня!

Ответ 15

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

Убедитесь, что вы изменили права собственности.

Ответ 16

Как правило, если это происходит в Windows, и вы используете tortoisegit, это кеш статуса tortoisegit. Убейте этот процесс, и он будет освобожден.

Ответ 17

Мне просто пришлось переключить пользователя с ubuntu на мое фактическое имя пользователя, которое я сначала делал. Это исправило это.

Ответ 18

Решил для меня, установив мой клиент git (GitExtensions) всегда в режиме администратора.

Ответ 19

У меня была эта проблема при использовании IntelliJ (14.1.3 Ultimate), я хотел отменить изменения в каком-то файле.

Решено, закрыв Git Bash, открытое в другом окне, - отработало другое повторное испытание в IntelliJ.

Ответ 20

Я столкнулся с этой ошибкой, и я думаю, что проблема заключалась в том, что я "запустил с правами администратора", когда запустил Eclipse и создал файлы, поэтому они принадлежали Admin (заметили, запустив "ls -la" в папке). Когда я позже попытался спрятать файлы, он не позволил мне ("невозможно удалить файлы" и все такое). Выполнение chmod для файлов было для меня исправлением.