53 votes

Fatal: impossible de verrouiller le stockage des identifiants : Le fichier existe

Je suis en train d'utiliser git-scm et j'ai essayé de pousser vers un dépôt. En le faisant, j'ai été accueilli par le message suivant :

fatal: impossible de verrouiller le stockage des identifiants : Le fichier existe

Malgré le fait que la poussée s'est effectuée avec succès, je me demande pourquoi cette erreur est apparue. Elle continue de se produire, alors qu'elle ne se produisait pas avant. Toute aide est appréciée. Merci !

5 votes

J'ai découvert qu'il y a un fichier /c/Users/USERNAME/.git-credentials.lock - mais lorsque je le supprime, j'obtiens une erreur d'assertion la prochaine fois que je lance git, et il y a un nouveau fichier de verrouillage. Ce qui conduit à une nouvelle erreur "lock: File exists". J'ai également découvert que j'avais deux paramètres différents pour credential.store, un dans mon répertoire personnel, et un autre dans /C/Program\ Files/Git/mingw64/etc/gitconfig. Enlever ce dernier n'a rien changé, même si git config -l ne montre désormais qu'un seul paramètre. Ainsi, ce problème reste un mystère pour moi. J'ai trouvé ceci : github.com/git-for-windows/git/issues/766

1 votes

Cela m'est arrivé après avoir "annulé" un git add ou commit. si vous appuyez sur CTRL+C dans git bash.

40voto

Zhe He Points 314

J'ai eu le même problème aujourd'hui. Il s'est avéré que j'avais d'une certaine manière deux configurations pour credential.helper. Utilisez git config --list pour vérifier si vous avez plusieurs credential.helper="XXX".

Dans mon cas, j'avais credential.helper=manager dans la configuration globale et credential.helper=store dans la configuration locale.

J'ai supprimé celui local dans chemin-vers-projet-git/.git/config et j'ai résolu le problème.

0 votes

Pour moi, je pense que cela a quelque chose à voir avec le nouveau gestionnaire d'identifiants des dernières versions de Git pour Windows. L'ancien paradigme était de définir credential.helper pour stocker et utiliser des clés d'authentification... maintenant il semble que Git pour Windows gérera votre compte en direct de manière interne par défaut

8 votes

Cela a résolu mon problème. J'ai aussi trouvé git config --list --show-origin utile, et git config --QUELLE --unset credential.helper où QUELLE est l'emplacement de l'entrée en faute, par exemple local, global ou system.

14voto

Shqear Points 41

Essayez de configurer votre gestionnaire d'informations d'identification sans utiliser --global

git config credential.helper wincred

1 votes

Fonctionne comme un charme :)

7voto

torek Points 25463

Le message d'erreur provient de git credential-store (cliquez pour accéder à la page de documentation). Il indique qu'une autre instance du programme de stockage des informations d'identification est actuellement en cours d'exécution et a verrouillé le fichier qui stocke (de manière non sécurisée, en texte clair) votre mot de passe.

Si aucune autre instance de git credential-store n'est réellement en cours d'exécution, il est fort probable que le fichier de verrouillage soit laissé par une exécution antérieure, et vous pouvez simplement le supprimer. Malheureusement, le programme ne vous indique pas l'emplacement du fichier spécifique contenant les informations d'identification (mais consultez la documentation pour les emplacements probables).

1voto

liberforce Points 4385

J'ai eu du mal à trouver où se trouvait le fichier de verrouillage. Sur Linux, utilisez simplement strace, mais n'oubliez pas de suivre les processus enfants avec l'option -f:

strace -f -eopen git credential-store --file=~/mystore store < creds
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/dev/null", O_RDWR)               = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/home/g179531/.gitconfig", O_RDONLY) = 3
Process 8269 attached
[pid  8269] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("~/mystore.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = -1 ENOENT (Aucun fichier ou dossier de ce type)
fatal: impossible de verrouiller le stockage des informations d'identification : Aucun fichier ou dossier de ce type
[pid  8269] +++ sorti avec 128 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8269, si_status=128, si_utime=0, si_stime=0} ---
+++ sorti avec 128 ++

Le dernier fichier que le programme a essayé d'ouvrir avant d'afficher l'erreur est le fichier de verrouillage. Dans mon cas, c'est ~/mystore.lock.

0 votes

Cela m'a aidé avec mon erreur 'No such file or directory'. Il essayait d'interpréter ~ comme un dossier à l'intérieur du répertoire actuel.

0 votes

Sur mon système, c'était dans ~/.git-credentials.lock

0 votes

Pour Windows, j'ai utilisé le moniteur de processus

1voto

Sonic Soul Points 4562

Dans mon cas sur Windows, un fichier git credentials .lock a été ajouté dans mon répertoire c:\utilisateurs\xxxx où se trouve toute la configuration git globale.

j'ai supprimé le fichier de verrouillage, ce qui a également supprimé le fichier de mots de passe git qui stockait mon mot de passe en clair.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X