git index.lock Файл існує, коли я намагаюся здійснити, але не можу видалити файл


197

Коли я роблю "git počin", я отримую наступне:

fatal: Unable to create 'project_path/.git/index.lock': File exists.

Однак, коли я ls project_path/.git/index.lockце роблю, я кажу, що файл не існує. Будь-які думки щодо того, що мені робити? Я також помітив, що project_path / .git належить root, не впевнений, чи має це щось спільне з проблемою, з якою я стикаюся.

версія git - 1.7.5.4

редагувати: Здається, що проблема, швидше за все, полягала в іншому процесі, який я запускав, - це написання (мені невідомого) в каталог проектів. Я перезапустив свою машину, і тоді у мене не виникло жодних проблем.


3
Це може бути проблемою дозволів, коли Git припускає, що оскільки він не може створити файл, він уже існує. Чи намагалися ви взяти право власності на каталог або виконати свою команду за допомогою sudo?

1
Я думаю, що ваше пояснення щодо іншого додатку, що отримує доступ до git repo, є правильним. Була така ж проблема під час перезавантаження. Gitx бігав. Як тільки я кинув його, Git спрацював чудово.
Хто

2
@asahi: Ви, можливо, хочете прийняти відповідь? Це допоможе майбутнім читачам.
MERose


3
@asahi: Ви можете опублікувати вміст своєї редакції (яка була рішенням) як відповідь, а потім прийняти це. (Хоча більш загальне рішення, ніж "перезапуск машини", полягає в тому, що інший процес отримував доступ до каталогу; перезапуск просто прорізає Гордіїв вузол, намагаючись зрозуміти, який з них і чому.) У моєму випадку це був мій IDE.) У будь-якому випадку люди часто відповідають на власні запитання, коли знаходять свої власні рішення, що ти і зробив.
Вілсон F

Відповіді:


330

Це може бути стара відповідь, але я сподіваюся, що це корисніше для наступних, хто потребує цього рішення.

На linux / unix / gitbash / cygwin, спробуйте

rm -f .git/index.lock

У командному рядку Windows спробуйте:

del .git\index.lock


1
Я бачу, що іноді файл блокування видаляється автоматично. Будь-яка підказка, чому цей файл іноді потрібно видаляти вручну?
Nrj

У мене немає index.lock, що робити? :(
Алекс С

56
Зважаючи на те, що проблема у питанні полягала в тому, що він не зміг видалити файл, чому ви вважаєте, що саме спроба видалити файл має бути рішенням?
злетіння

4
Для мене закриття та відкриття SourceTree вирішило проблему ... Тимчасово я думаю.
Андрій

1
@skyking в оригінальному запитанні є помилка, яка говорить fatal: Unable to create 'project_path/.git/index.lock': File exists.: "Файл існує", і видалення його буде простим рішенням. Чому я б запропонував видалити файл, якщо він навіть не в оригінальному запитанні?
Ryan S

40

Для Windows:

  • На консолі потужності, відкритій як адміністратор, спробуйте
> rm -Force ./.git/index.lock
  • Якщо це не працює, ви повинні вбити всі процеси git.exe
> taskkill /F /IM git.exe
SUCCESS: The process "git.exe" with PID 20448 has been terminated.
SUCCESS: The process "git.exe" with PID 11312 has been terminated.
SUCCESS: The process "git.exe" with PID 23868 has been terminated.
SUCCESS: The process "git.exe" with PID 27496 has been terminated.
SUCCESS: The process "git.exe" with PID 33480 has been terminated.
SUCCESS: The process "git.exe" with PID 28036 has been terminated.
> rm -Force ./.git/index.lock

1
Параметр неможливо обробити, оскільки ім'я параметра "f" неоднозначне.
3pitt

дякую, @MikePalmice, я оновив до -Force. Здається, вони змінили API
Андрій Епуре

20

На платформі Windows, на якій працює Visual Studio 2015 RC (v4.6.00057) у поєднанні з SourceTree (v1.6.14.0), буде також ця помилка.

Рішення. Припустимо, що ви хочете використовувати джерельне дерево як менеджер вихідного коду, просто відключіть постачальник керування джерелом у Visual Studio, як це:

  1. Перейдіть до: Інструменти> Параметри> Контроль джерела
  2. Виберіть плагін управління поточним джерелом як: Ні

Навіть незважаючи на те, що мій VS не повинен мати навіть доступу до цих сховищ, це все-таки була проблема при перезавантаженні з SourceTree.
Kajetan Abt

Дякую, проблема все ще існує з оновленням 3.
Elger Mensonides

Закриття Visual Studio також працює (видалено файл index.lock.)
misterbee

10
  1. перевірте, чи git все ще працює (ps -ef | grep git)
  2. якщо ні, видаліть заблокований файл
  3. якщо так, спочатку вбийте процес git.

9

спробуйте

rm -f ./.git/index.lock

якщо у вас немає іншого запущеного процесу git, просто видаліть файл index.lock відповідного проекту.


Працював над оточенням мого Mac.
Адам Гурвіц

6

Щойно виникла ця проблема ... Gitbox винен. Тож, можливо, у вас працював графічний інтерфейс, який створював проблеми.


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

Схоже, GitX любить викликати і цю проблему.
Glutexo

Через 6 років це був Атом для мене
молоко

6

Це відбувається, коли ви скасуєте тягнення від походження посередині.

тож ви можете вручну видалити файл index.lock із каталогу .git.

rm -f ./.git/index.lock

CD у ваш каталог проектів і запустіть цю команду.


8
Зважаючи на те, що проблема у питанні полягала в тому, що він не зміг видалити файл, чому ви вважаєте, що саме спроба видалити файл має бути рішенням?
злетіння

+1 @skyking. Видалення файлу очевидно, проблема в тому, що немає файлу для видалення, і проблема зберігається.
Кацунамі

6
  1. Закрийте кожне вікно, яке потенційно впливає на цей .git / index.lock файл
  2. Видаліть файл .git / index.lock.
  3. Відкрийте редактор командного рядка та перейдіть до місця розташування файлів git.

(Якщо файл створений просто з CD у тому місці, тоді проблема полягає у вашому редакторі. Закрийте редактор. Не використовуйте цей редактор знову для цього завдання. Відкрийте інший тип редактора - оболонку живлення Windows або просто cmd. Тепер ви можете використовувати команди git для продовження)


5

Напевно (це трапилося зі мною) команда ls каже, що її не існує, оскільки поточний користувач не має дозволу на те, щоб досягти цього каталогу чи файлу.

Вийміть замок і переконайтеся, що виконайте git з потрібним користувачем , щоб уникнути проблем з дозволом.

Якщо ви знаходитесь у вікні GNU / Linux із командою sudo :

sudo rm project_path / .git / index.lock


У Windows можна перевірити, чи папка доступна лише для читання правою кнопкою миші-> Властивості-> Атрибути.
Метт

Зважаючи на те, що проблема в питанні полягала в тому, що файл не існує, чому ви вважаєте, що саме спроба видалити файл має бути рішенням?
злетіння

@skyking Проблеми з дозволом показують ту саму помилку. Дійсно, я прийшов до цього питання через те, що назва. Я написав свою відповідь як одне можливе рішення, і деякі голоси підтверджують, що вона трапляється і для інших людей;)
caligari

@caligari Не зовсім. Проблема дозволу дає ще одну відповідь на ls project_path/.git/index.lock.
злетіння

5

del .git\index.lock працював на мене.

Я зіткнувся з цим питанням під час оформлення нової гілки з головного відділення.

Оформити замовлення легко після видалення index.lockфайлу.


4

Іноді Git створює файл блокування, пов’язаний з вашим репо, під час внесення змін або, швидше за все, під час використання під модулів. Повідомлення про помилку покаже вам шлях до файлу блокування. Виправлення: просто вручну перейдіть до контуру в терміналі та видаліть файл блокування за допомогою $ rm index.lock

Це повинно допомогти.


4

У мене була ця проблема з SourceTree при перемиканні гілки подвійним клацанням по ній. Проблема не дуже поширена, і про неї знають атласіанці, але вони вирішили її не вирішувати.

На щастя, рішення є. Замість того, щоб двічі клацнути на гілці, яку потрібно переключити, просто клацніть правою кнопкою миші та виберіть "Оформити замовлення [назва гілки]". Це має досягти успіху зараз.


дякую, клацніть правою кнопкою миші> замовлення працює як альтернатива. повідомлення про помилку є досить оманливим, особливо коли index.lock не існує.
Ернест

4

Я натрапив на той самий сценарій. Я навіть не змінив свого місцевого коду. Я щойно відредагував файл і відновив його. Я просто видалив файл нижче в прихованій .git папці. Це спрацювало!

project_path / .git / index.lock


3

Якщо ви насправді не мали наміру мати root для власного репо, це здається, що ви випадково запустили команду Git як root (можливо, навіть початковий клон / ініт). Якщо ви мали намір це зробити, тоді вам доведеться жити, виконуючи всі команди Git в репо як кореневі. Якщо ви цього не зробите, запустіть sudo chown your-user[:your-group] -R .gitправо власності на нього, а потім подивіться, чи все працює.


У моєму випадку я переплутав режим файлів і каталогів всередині, .gitі я виправив їх: find .git -type f -exec chmod 644 {} \;а також find .git -type d -exec chmod 755 {} \;я переплутав режими, коли переміщував мій проект git з одного комп’ютера на інший
user3405291

У моєму випадку я додав дозвіл на написання файлів .gitsudo chmod g+w .git -R
Beatriz Fonseca

2

Кілька клієнтів git, що працюють в одному локальному сховищі, конкурують за цей замок. Кожен клієнт повинен дочекатися, коли інша сторона звільнить замок, щоб стати хорошим громадянином. Для нас, схоже, SourceTree або MSVS виконують певне обслуговування у фоновому режимі, поки ми виконуємо великі сценарії фіксації.

Можливо, сам git повинен підтримувати аргумент '--retriesWhenLocked 5' для підтримки повторних спроб. або навіть за замовчуванням до цього, коли запускається вручну

Ось обгортка PowerShell навколо git з назвою "gitr", яка намагається повторити, поки не зникне index.lock, використовуючи 5 спроб за замовчуванням, 3 секунди між кожною. Він ніколи не видаляє index.lock, припускаючи, що користувач повинен втрутитися. Він був вилучений із більшого сценарію фіксації. Це лише мінімальне тестування з простими аргументами.

  • Скопіюйте скрипт у C: \ bin та додайте C: \ bin до $ PATH.
  • Від PS1> gitr --help
  • Від DOS%> powershell gitr --help

gitr.ps1

    #requires -version 2
    <#
    .SYNOPSIS
        gitr
    .DESCRIPTION
        Run "git" as an external process with retry and capturing stdout stderr.
    .NOTES  
      2017/05/16 crokusek: Initial version
    #>

    #---------------------------------------------------------[Initializations]--------------------------------------------------------

    #Set Error Action 
    $ErrorActionPreference = "Stop";

    #----------------------------------------------------------[Declarations]----------------------------------------------------------

    $scriptDir = Split-Path $script:MyInvocation.MyCommand.Path
    #Set-Location $scriptDir

    ## Disabled logging
    # Log File 
    # $logFile = "$($scriptDir)\getr.log"
    # If (Test-Path $logFile) { Clear-Content $logFile }

    #-----------------------------------------------------------[Functions]------------------------------------------------------------

    Function Log([string]$msg, [bool]$echo = $true)
    {
        $timestamp = "$(get-date -Format 'yyyy/MM/dd HH:mm:ss'):  " 
        $fullmsg = $msg -replace '(?ms)^', $timestamp  # the (?ms) enables multiline mode

        ## Disabled Logging 
        # Add-content $LogFile -value $fullmsg

        if ($echo)
        {
            Write-Host $msg
        }
    }

    Function ExecSimple([string]$command, [bool]$echo=$true, [bool]$stopOnNonZeroExitCode=$true)
    {
        $command, $args = $command -split " "
        return Exec $command $args $echo $stopOnNonZeroExitCode
    }

    Function Exec([string]$exe, [string[]]$arguments, [bool]$echo=$true, [bool]$stopOnNonZeroExitCode=$true)
    {   
        # Passing $args (list) as a single parameter is the most flexible, it supports spaces and double quotes

        $orgErrorActionPreference = $ErrorActionPreference 
        Try
        {           
            $error.clear()  # this apparently catches all the stderr pipe lines

            if ($false -and $exe -eq 'git')  # todo make this a generic flag
            {
                $exe = "$($exe) 2>&1"
            }

            $output = ""

            $argflattened = $arguments -join ' '
            Log "`n% $($exe) $($arguments)`n"

            # This way some advantages over Invoke-Expressions or Start-Process for some cases:
            #      - merges stdout/stderr line by line properly, 
            #      - echoes the output live as it is streamed to the current window,
            #      - waits for completion
            #      - works when calling both console and windows executables.
            #       
            $ErrorActionPreference = "Continue"  # required in order to catch more than 1 stderr line in the exception

            if ($echo)
            {
                # Using "cmd.exe" allows the stderr -> stdout redirection to work properly.  Otherwise the 2>&1 runs after PS for 
                # some reason.  When a command such as "git" writes to stderr, powershell was terminating on the first stderr 
                # line (and stops capturing additional lines).
                #
                # but unfortuantely cmd has some bizarre de-quoting rules that weren't working for all cases. 
                #& cmd /c "`"" $exe $arguments "`"" | Tee-Object -variable output | Write-Host | out-null           

                # This is simplest but has some issues with stderr/stdout (stderr caught as exception below)
                #
                & $exe $arguments 2>&1 | tee -variable output | Write-Host | out-null 
            }
            else
            {           
                & $exe $arguments 2>&1 | tee -variable output | out-null 
            }

            $output = $output -join "`r`n"                  

            if ($stopOnNonZeroExitCode -and !$LASTEXITCODE -eq 0)
            {           
                throw [System.Exception] "Exit code ($($LASTEXITCODE)) was non-zero. Output:`n$($output)"
            }       
        }
        catch [System.Management.Automation.RemoteException]
        {
            $output = $_.Exception.ToString().Replace("System.Management.Automation.RemoteException:", "").Trim()

            if ($output.Contains("fatal")) 
            {
                throw 
            }

            if ($echo)
            {
                Log $output
            }
        }
        finally
        {
            $ErrorActionPreference = $orgErrorActionPreference;
        }

        if (-not $output -eq "")
        {
            Log $output $false  # don't echo to screen as the pipe above did    
        }

        return $output
    }

    Function ExecWithRetry([string]$exe, [string[]]$arguments, [bool]$echo=$true, [bool]$stopOnNonZeroExitCode=$true, 
                          [int]$maxRetries = 5, [int]$msDelay = 3000, [AllowNull()][string]$exceptionMustContain = $null)
    {
        for ($i = 0; $i -lt $maxRetries; $i++)
        {
            try
            {
                Exec $exe $arguments $echo $stopOnNonZeroExitCode
                return
            }
            catch
            {
                if (-not [string]::IsNullOrEmpty($exceptionMustContain) -and $_.Exception.ToString().Contains($exceptionMustContain))
                {
                    Log "Last Error from $($exe) is retryable ($($i + 1) of $($maxRetries))" $true
                    Start-Sleep -Milliseconds ($msDelay);
                    continue
                }

                throw
            }
        }

        throw [System.Exception] "Unable to successfully exec '$($exe)' within $($maxRetries) attempts."
    }

    Function GitWithRetry([string[]]$arguments, [bool]$echo=$true)
    {
        ExecWithRetry "git" $arguments $echo -exceptionMustContain "Another git process seems to be running"
    }

#-----------------------------------------------------------[Main]------------------------------------------------------------

function Main([string[]]$arguments)
{   
    GitWithRetry @($arguments)
}


#-------------------------------------- Startup ------------------------------------
try 
{
    Main $args
    Exit 0
}    
catch
{
    #Log "*** A fatal error occured: $($_.Exception)"
    #Read-Host -Prompt "`nA fatal error occurred, press enter to close."    
    exit 1
}

2

У мене також є це питання у Windows 10.

коли я спробую дель ./.git/index.lock, це мені сказалоcannot remove 'index.lock': Device or resource busy

Нарешті я отримав причину:

комп'ютер має два процеси для використання git:

  • git bash
  • cmder

тому я використовую cmder.exe, щоб у git commitньому виникли помилки.

тож рішення - це використання git bashабо припинення git bashвикористання cmder.exe


1

У мене була така сама помилка, але проблема не в файлі блокування. Натомість проблема полягала в тому, що я скопіював вміст ще одного git repo в це репо, включаючи невидиму папку .git. Отже, SourceTree розгубився з приводу того, до якого репо я хотів поставити файли (між невідповідністю репо SourceTree подумав, що я перебуваю, і тим, що вміст мого вбудованого. Git dir сказав, що я повинен бути).


1

У мене була ця проблема з TortoiseGit із Cygwin у Windows. Я не зміг видалити видалити ./.git/index.lock навіть з адміністративними привілеями, я спробував як Cygwin, так і командний рядок, він сказав, що файл використовується іншим процесом.

Я виявив, що у мене запущено 2 екземпляри TortoiseProc.exe. Я вбив одного з них і закрив усі свої вікна Explorer Explorer, а потім зміг видалити файл. Я не знаю, чи вбивство екземпляра TortoiseProc.exe було рішенням або закриттям Windows Explorer.


1

Для мене рішення було видалити .index файл і дозволити Git відновити інший.


1

У мене не було файлу unu.lock для видалення, але те, що для мене спрацювало, було видалити прапорець Лише для читання з вікна Атрибути діалогового вікна Властивості папки.



1

Починаючи з git 2.8.4 (червень 2016 року) , цього більше не повинно відбуватися.

Дивіться випуск 755, який також повинен полегшити проблему ( призначати 2db0641 ):

Переконайтесь, що дочірні процеси не успадковують дочірніх файлів

Запобігання дочірнім процесам від успадкування ручки до index.lock.


1

У моєму додатку sourceTree я не в змозі зробити фіксацію або перейти на будь-яку іншу комісію / браш. Цей час показує помилки, як

фатально: Не вдається створити бла-бла-бла ..

Я просто вирішую це за допомогою goto .git папки (у проекті Explorer Dir). І видаліть індекс ----- [тип файлу: файл LOCK]. Тепер я отримую назад весь доступ у sourceTree ..

будь ласка, переконайтеся, що файл блокування індексу .. припустимо, ви не отримуєте тип файлу, змінюєте параметри перегляду файлів на комп’ютері. Примітка: папка .git зазвичай прихований тип папки.


1

Що для мене це було:

git rebase --abort та перезавантажте ребазу.

Як згадував Ендрю, я також використовував PHPStorm, коли це сталося. Закривати це не довелося.


1

Спочатку вам потрібно перейти до конкретної папки вашого проекту. Начебто, якщо ім'я вашого проекту є Firstproject, то спочатку перейдіть до каталогу проекту .. потім введіть cd .git, а потім після переходу до папки git типу del index.lock Після видалення файлу index.lock..Ви зможете здійснити та натиснути, як раніше


1

У моєму випадку це були вікна, а не закриті повністю.

Вікна перебувають у сплячому режимі, відмовляються монтувати

Ймовірно, що Windows дійсно перебуває в сплячому режимі. Windows робить це автоматично, коли ви скажете йому нормально відключитися. Перевага полягає в тому, що ви отримуєте швидший очевидний час запуску.

Щоб вимкнути Windows без гібернації, в командному рядку (в Windows) видайте таке:

shutdown /s

Ви також можете включити /t 0для негайного відключення.

Я знайшов чудовий посібник, щоб налаштувати пускову програму для цього: Як зробити повне відключення в Windows 8 без відключення гібридної завантаження.

Найпростіший підхід до фактичного вимкнення Windows - це «перезапуск» (а не «вимикання»), а потім перехоплення процесу завантаження та завантаження Linux, а не дозволяти йому завантажувати Windows.

кредит : nobar


1

Це також може статися , якщо ви використовуєте альтернативний GIT клієнт командного рядка, як концентратор .

Я використовую концентратор як псевдонімна заміна для git протягом декількох років, але нещодавно написав bash-скрипт, який робить в ньому купу git, і почав отримувати цю проблему блокування індексу.

Я не зміг знайти виправлення, поки не згадав, що запускаю концентратор замість git. Я це зняв, і проблема пішла!


0

Отримання помилки:

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
fatal: Unable to create '/home/user/project/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

Але я не зміг знайти (ні видалити) цей .git / index.lock файл.

У моєму випадку працювала git-cola!

Вочевидь, це створює .git / index.lock раз у раз, або викликаний ребазою, яку я робив у командному рядку, і під час якої я отримав цю помилку - тому git-cola явно «порушує» запуск командного рядка Git (або деякі операції Git CLI).

Це вирішується шляхом закриття git-cola під час відновлення бази даних git.


0

Іноді інший клієнт Git може заважати, коли встановлено декілька.

Тобто переконайтеся , що з Task Manager або Get-Processщо TGitCacheз TortoiseGit не працює у фоновому режимі.


0

У мене був такий самий випуск нещодавно. Якщо ви перевірите все повідомлення про помилку, воно також говорить про те, що є якийсь процес, який використовує процес git, який блокує вас для видалення index.lock. У вас може бути відкрито IDE, як Visual Studio або пов'язане з ним програмне забезпечення, в яке вбудовано git. Закрийте його і спробуйте повторно зберігати файл. Сподіваюся, це допомагає.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.