git index.lock Le fichier existe lorsque j'essaie de valider, mais je ne peux pas supprimer le fichier


197

Lorsque je fais «git commit», j'obtiens ce qui suit:

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

Cependant, lorsque je le fais, ls project_path/.git/index.lockcela signifie que le fichier n'existe pas. Avez-vous des réflexions sur ce que je dois faire? J'ai également remarqué que project_path / .git appartient à root, je ne sais pas si cela a quelque chose à voir avec le problème que je rencontre.

la version git est 1.7.5.4

edit: Il semble que le problème était probablement un autre processus que j'avais en cours d'exécution, qui écrivait (à mon insu) dans le répertoire du projet. J'ai redémarré ma machine, puis je n'ai eu aucun problème à m'engager.


3
Il pourrait très bien s'agir d'un problème d'autorisations où Git suppose que puisqu'il ne peut pas créer le fichier, il existe déjà. Avez-vous essayé de vous approprier le répertoire ou d'exécuter votre commande à l'aide de sudo?

1
Je pense que votre explication sur une autre application accédant au dépôt git est correcte. Eu le même problème lors d'un rebase. Gitx courait. Une fois que j'ai arrêté, ça a bien marché.
The Who

2
@asahi: Voulez-vous peut-être accepter une réponse? Cela aidera les futurs lecteurs.
MERose


3
@asahi: Vous pouvez publier le contenu de votre modification (qui était la solution) comme réponse, puis l'accepter. (Bien que la solution plus générale que `` redémarrer la machine '' soit qu'un autre processus accède au répertoire; le redémarrage coupe simplement le nœud gordien d'essayer de déterminer lequel et pourquoi.:) Dans mon cas, c'était mon IDE.) Quoi qu'il en soit, les gens répondent souvent à leurs propres questions lorsqu'ils trouvent leurs propres solutions, ce que vous avez fait.
Wilson F

Réponses:


328

Cela peut être une vieille réponse, mais j'espère que cela sera plus utile pour les prochains qui ont besoin de cette solution.

Sur linux / unix / gitbash / cygwin, essayez

rm -f .git/index.lock

Sur l'invite de commande Windows, essayez:

del .git\index.lock


1
Je vois que parfois le fichier de verrouillage est supprimé automatiquement. Quel indice pourquoi ce fichier doit être supprimé manuellement parfois?
Nrj

Je n'ai pas de index.lock, que faire? :(
Alex C

56
Étant donné que le problème dans la question était qu'il n'était pas en mesure de supprimer le fichier, pourquoi pensez-vous que la suppression du fichier devrait être la solution?
skyking

4
Pour moi, la fermeture et l'ouverture de SourceTree ont résolu le problème ... temporairement, je suppose.
Andrew

1
@skyking dans la question d'origine, il y a une erreur qui dit fatal: Unable to create 'project_path/.git/index.lock': File exists., il dit "Le fichier existe", et la supprimer serait une solution simple. Pourquoi suggérerais-je de supprimer un fichier s'il ne figure même pas dans la question d'origine?
Ryan S

40

Pour les fenêtres:

  • À partir d'une console PowerShell ouverte en tant qu'administrateur, essayez
> rm -Force ./.git/index.lock
  • Si cela ne fonctionne pas, vous devez tuer tous les processus 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
Le paramètre ne peut pas être traité car le nom de paramètre «f» est ambigu.
3pitt

merci, @MikePalmice, j'ai mis à jour -Force. Semble avoir changé l'API
Andrei Epure

20

Sur une plate-forme Windows exécutant Visual Studio 2015 RC (v4.6.00057) en combinaison avec SourceTree (v1.6.14.0) donnera également cette erreur.

Solution: en supposant que vous souhaitez utiliser l'arborescence source comme gestionnaire de code source, désactivez simplement le fournisseur de contrôle de source dans Visual Studio comme ceci:

  1. Accédez à: Outils> Options> Contrôle de source
  2. Sélectionnez le plug-in de contrôle de source actuel comme: Aucun

Même si mon VS n'est pas censé même accéder à ces référentiels, c'était de toute façon le problème lors du rebasage avec SourceTree.
Kajetan Abt

Merci, le problème est toujours là avec la mise à jour 3.
Elger Mensonides

La fermeture de Visual Studio fonctionne également (suppression du fichier index.lock.)
misterbee

10
  1. vérifier si le git fonctionne toujours (ps -ef | grep git)
  2. sinon, supprimez le fichier verrouillé
  3. si oui, tuez d'abord le processus git.

9

essayer

rm -f ./.git/index.lock

si aucun autre processus git n'est en cours d'exécution, supprimez simplement le fichier index.lock du projet respectif.


A travaillé sur l'environnement de mon mac.
Adam Hurwitz

6

Je viens d'avoir ce problème ... Gitbox était en faute. Alors peut-être que vous aviez une interface graphique en cours d'exécution qui posait des problèmes.


Ce n'était pas une interface graphique mais j'avais un processus distinct qui écrivait dans le répertoire du projet. Je ne pouvais pas le comprendre et cela me rendait fou.
asahi

Il semble que GitX aime aussi causer ce problème.
Glutexo

6 ans plus tard, c'était Atom pour moi
Milk

6

Cela se produit lorsque vous annulez l'extraction de l'origine au milieu.

vous pouvez donc supprimer manuellement le fichier index.lock de votre répertoire .git.

rm -f ./.git/index.lock

cd dans votre répertoire de projet et exécutez cette commande.


8
Étant donné que le problème dans la question était qu'il n'était pas en mesure de supprimer le fichier, pourquoi pensez-vous que la suppression du fichier devrait être la solution?
skyking

+1 @skyking. La suppression d'un fichier est évidente, le problème est qu'il n'y a pas de fichier à supprimer et le problème persiste.
Catsunami

6
  1. Fermez toutes les fenêtres susceptibles d'affecter ce fichier .git / index.lock
  2. Supprimez le fichier .git / index.lock.
  3. Ouvrez votre éditeur de ligne de commande et cd à l'emplacement de vos fichiers git.

(Si le fichier est créé, simplement à partir du CD à cet emplacement, le problème est votre éditeur. Fermez votre éditeur. N'utilisez plus cet éditeur pour cette tâche. Ouvrez un autre type d'éditeur - Windows Power Shell ou simplement cmd. Maintenant vous pouvez utiliser les commandes git pour continuer)


5

Probablement (cela m'est arrivé), la commande ls dit qu'elle n'existe pas car l'utilisateur actuel n'a pas les autorisations pour accéder à ce répertoire ou fichier.

Retirez le verrou et assurez-vous que vous exécutez git avec le bon utilisateur afin d'éviter les problèmes d'autorisation.

Si vous êtes dans une boîte GNU / Linux avec la commande sudo :

sudo rm chemin_projet / .git / index.lock


Sous Windows, vous pouvez vérifier si le dossier est en lecture seule avec un clic droit-> Propriétés-> Attributs.
Matt

Étant donné que le problème dans la question était que le fichier était inexistant, pourquoi pensez-vous que la suppression du fichier devrait être la solution?
skyking

Les problèmes d'autorisation @skyking affichent la même erreur. En effet, je suis venu à cette question parce que le titre. J'ai écrit ma réponse comme une solution possible et certains votes confirment qu'elle se produit aussi pour d'autres personnes;)
caligari

@caligari Pas exactement. Le problème d'autorisation donne une autre réponse à ls project_path/.git/index.lock.
skyking

5

del .git\index.lock travaillé pour moi.

J'étais confronté à ce problème lors du paiement d'une nouvelle branche de la branche principale.

Le paiement s'est facilement produit après la suppression du index.lockfichier.


4

Parfois, Git crée un fichier de verrouillage associé à votre dépôt lorsque vous effectuez des modifications ou très probablement lorsque vous utilisez des sous-modules. Le message d'erreur vous montrera le chemin du fichier de verrouillage. Corrigé: Accédez simplement manuellement au chemin dans le terminal et supprimez le fichier de verrouillage par $ rm index.lock

Ça devrait aider.


4

J'ai eu ce problème avec SourceTree lors du changement de branche en double-cliquant dessus. Le problème n'est pas très courant et Atlassian le sait mais ils ont décidé de ne pas le résoudre.

Heureusement, il existe une solution. Au lieu de double-cliquer sur la branche que vous souhaitez changer, faites un clic droit et choisissez "Checkout [nom de la branche]". Cela devrait réussir maintenant.


merci, clic droit> checkout fonctionne comme une alternative. le message d'erreur est assez trompeur, surtout lorsque index.lock n'existe pas.
Ernest

4

J'ai rencontré le même scénario. Je n'ai même pas fait de changements dans mon code local. Je viens de modifier un fichier et de le rétablir. J'ai simplement supprimé le fichier ci-dessous dans le dossier caché .git. Ça a marché!

chemin_projet / .git / index.lock


3

À moins que vous ne souhaitiez réellement que root possède votre référentiel, cela semble que vous avez accidentellement exécuté une commande Git en tant que root (peut-être même le clone / init initial). Si vous vouliez le faire, vous devrez vivre avec l'exécution de toutes les commandes Git dans le référentiel en tant que root. Si ce n'est pas le cas, courez sudo chown your-user[:your-group] -R .gitpour en prendre possession, puis voyez si les choses fonctionnent.


Dans mon cas, j'avais foiré le mode des fichiers et des répertoires à l'intérieur .gitet je les ai corrigés avec: find .git -type f -exec chmod 644 {} \;et find .git -type d -exec chmod 755 {} \;j'avais également foiré les modes lors du déplacement de mon projet git d'un ordinateur à l'autre
user3405291

Dans mon cas, j'ai ajouté une autorisation d'écriture aux fichiers .gitsudo chmod g+w .git -R
Beatriz Fonseca

2

Plusieurs clients git travaillant sur le même référentiel local se disputent ce verrou. Chaque client doit attendre que le verrou soit libéré par l'autre partie pour être un bon citoyen. Pour nous, SourceTree ou MSVS semblent effectuer une maintenance en arrière-plan pendant que nous exécutions de gros scripts de validation.

Peut-être que 'git' lui-même devrait supporter un argument '--retriesWhenLocked 5' pour supporter les tentatives. ou même par défaut à cela lorsqu'il est exécuté manuellement.

Voici un wrapper PowerShell autour de git nommé "gitr" qui réessaye jusqu'à ce que index.lock disparaisse, en utilisant 5 essais par défaut, 3 secondes entre chacun. Il ne supprime jamais le fichier index.lock, en supposant que l'utilisateur doit intervenir. Il a été extrait d'un script de validation plus grand. Il n'a que peu de tests avec des arguments simples.

  • Copiez le script dans C: \ bin et ajoutez C: \ bin dans $ PATH.
  • Depuis PS1> gitr --help
  • Depuis 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

J'ai également cette question dans Windows 10.

quand j'essaie del ./.git/index.lock, ça m'a ditcannot remove 'index.lock': Device or resource busy

J'ai finalement compris la raison:

l'ordinateur a deux processus pour utiliser git:

  • git bash
  • cmder

donc j'utilise cmder.exe pour git commitqu'il se produise des erreurs.

de sorte que la solution consiste à utiliser git bashou mettre fin à git bashpuis utiliser cmder.exe


1

J'ai eu exactement la même erreur, mais le problème n'était pas le fichier de verrouillage. Au lieu de cela, le problème était que j'avais copié le contenu d'un autre dépôt git dans ce dépôt, y compris le dossier invisible .git. Ainsi, SourceTree était confus quant au repo dans lequel je voulais mettre en scène les fichiers (il y avait un décalage entre le repo que SourceTree pensait que j'étais, et celui dans lequel le contenu de mon dir .git incorporé disait que je devrais être).


1

J'ai eu ce problème avec TortoiseGit avec Cygwin sous Windows. Je n'ai pas pu supprimer remove ./.git/index.lock même avec des privilèges administratifs, j'ai essayé à la fois Cygwin et l'invite de commande, il a déclaré que le fichier était utilisé par un autre processus.

J'ai constaté que j'avais 2 instances de TortoiseProc.exe en cours d'exécution. J'ai tué l'un d'eux et fermé toutes mes fenêtres de l'explorateur Windows, puis j'ai pu supprimer le fichier. Je ne sais pas si tuer une instance de TortoiseProc.exe était la solution ou fermer les fenêtres de l'explorateur Windows.


1

La solution pour moi était de supprimer le fichier .index et de permettre à Git d'en reconstruire un autre.


1

Je n'avais pas de fichier inex.lock à supprimer, mais ce qui a fonctionné pour moi a été de supprimer la vérification en lecture seule de la fenêtre Attributs de la boîte de dialogue Propriétés du dossier.


1

J'ai créé un fichier index.lock vide, je l'ai supprimé à l'aide de la commande windows


1

À partir git 2.8.4 (Juin 2016) , cela ne devrait pas se produire plus.

Voir le numéro 755 qui devrait également résoudre le problème ( commit 2db0641 ):

Assurez-vous que les descripteurs de fichiers temporaires ne sont pas hérités par les processus enfants

Empêcher les processus enfants d'hériter d'un handle vers index.lock.


1

Dans mon application sourceTree, je ne suis pas en mesure de valider ou de basculer vers un autre commit / brach. Ce temps montre une erreur comme

fatal: impossible de créer bla bla bla ..

Je résous simplement cela par le dossier goto .git (dans le projet Explorer Dir). Et supprimez l'index ----- [type de fichier: fichier LOCK]. Maintenant, je récupère tous les accès dans sourceTree ..

s'il vous plaît assurez-vous que le fichier de verrouillage d'index .. suppose que vous n'obtenez pas le type de fichier, modifiez les paramètres de la vue du fichier dans l'ordinateur. Remarque: le dossier .git est normalement un type de dossier caché.


1

Qu'est-ce que cela m'a fait:

git rebase --abort et redémarrez le rebase.

Comme Andrew l'a mentionné, j'utilisais également PHPStorm lorsque cela s'est produit. Je n'ai pas eu à le fermer cependant.


1

Vous devez d'abord naviguer vers le dossier spécifique de votre projet .. Comme si le nom de votre projet est Firstproject puis allez d'abord dans le répertoire du projet .. puis tapez cd .git puis après avoir accédé au dossier git, tapez del index.lock Après la suppression du fichier index.lock..Vous pourrez valider et pousser comme avant


1

Dans mon cas, c'était des fenêtres, pas complètement fermées.

Windows est en veille prolongée, a refusé de monter

Il y a de fortes chances que Windows soit vraiment en veille prolongée. Windows le fait automatiquement lorsque vous lui dites de s'arrêter normalement. L'avantage est que vous obtenez un temps de démarrage apparent plus rapide.

Pour arrêter Windows sans hybernation, émettez ce qui suit à l'invite de commande (sous Windows):

shutdown /s

Vous pouvez également vouloir inclure /t 0pour un arrêt immédiat.

J'ai trouvé un bon tutoriel pour configurer un lanceur pour cela: Comment faire un arrêt complet dans Windows 8 sans désactiver le démarrage hybride.

L'approche la plus simple pour arrêter réellement Windows consiste à «redémarrer» (plutôt qu'à «arrêter»), puis à intercepter le processus de démarrage et à démarrer Linux au lieu de le laisser démarrer Windows.

crédit : nobar


1

Cela peut également se produire si vous utilisez un autre client git en ligne de commande, comme hub .

J'utilise hub comme remplacement alias de git depuis quelques années, mais j'ai récemment écrit un script bash qui fait un tas de travaux git et j'ai commencé à obtenir ce problème de verrouillage d'index.

Je n'ai pas pu trouver le correctif jusqu'à ce que je me souvienne que j'utilisais le hub au lieu de git. J'ai supprimé cela et le problème a disparu!


0

Obtenir l'erreur:

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.

Mais je n'ai pas pu trouver (ni supprimer) ce fichier .git / index.lock.

Dans mon cas, git-cola courait!

Il crée évidemment ce .git / index.lock de temps en temps, ou causé par le rebase que je faisais sur la ligne de commande et pendant lequel j'ai reçu cette erreur - donc git-cola "perturbe" évidemment la ligne de commande de Git (ou certaines opérations de Git CLI).

Ceci est résolu en fermant git-cola lors d'un rebase de git en ligne de commande.


0

Parfois, un autre client Git peut interférer lorsqu'il y en a plusieurs installés.

C'est à dire. assurez-vous que le Gestionnaire des tâches ou Get-Processcelui TGitCachede TortoiseGit n'est pas actif en arrière-plan.


0

J'ai eu le même problème récemment. Si vous vérifiez l'ensemble du message d'erreur, il indique également qu'il existe des processus utilisant le processus git qui vous empêchent de supprimer index.lock. Vous pouvez avoir IDE ouvert comme Visual Studio ou un logiciel connexe dans lequel git est intégré. Fermez-le et réessayez de ranger votre fichier. J'espère que ça aide.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.