git rebase: "erreur: impossible de stat 'fichier': autorisation refusée"


343

J'utilise git et j'ai fait un petit commit suivi d'un gros. J'ai décidé d'utiliser git rebasepour écraser les deux commits ensemble avant de les pousser. (Je n'ai jamais fait cela auparavant.)

J'ai donc fait:

git rebase -i HEAD~2

Cela m'a donné mon éditeur, où j'ai choisi de choisir le commit précédent et d'écraser le dernier. Quand j'ai sauvé, git a dit:

erreur: impossible de stat ' nom de fichier ': autorisation refusée

Impossible d'appliquer sha1 pour une validation ultérieure ... ligne de texte initiale pour cette validation

Maintenant:

  • Aucun commit n'apparaît quand je le fais git log.
  • git status me dit que je ne suis "actuellement sur aucune branche".
  • Un fichier est répertorié comme modifié et dans l'index, et deux fichiers sont répertoriés comme non suivis. Mon premier commit n'avait qu'un seul fichier (je pense), et mon second commit en avait une bonne douzaine.

Qu'est-il arrivé!? Comment je le répare?


10
Utilisez-vous par hasard git sur windows?
CB Bailey

Oui. J'exécute les commandes dans une fenêtre DOS.
Ryan Lundy

2
Utilisez-vous un antivirus? Parfois, les programmes antivirus de mauvaise qualité peuvent provoquer des problèmes comme celui-ci.
Greg Hewgill

53
J'ai eu le problème avec git checkout (donc aucun abandon possible comme suggéré par la réponse acceptée) mais la fermeture de tous mes IDE m'a laissé passer. La deuxième réponse devrait être celle acceptée
plus

1
@IanGrainger, la réponse à laquelle vous faites référence a été publiée huit mois après la réponse acceptée. Dois-je faire un tour et visiter toutes mes questions tous les quelques mois pour éventuellement changer les réponses acceptées sur chacune d'entre elles? Les boutons de vote sont là pour une raison. Si la réponse la plus votée vous aide plus que la réponse acceptée, utilisez-la. Qui t'arrête? Mais j'ai accepté la réponse que j'ai faite parce que cela m'a aidé, et c'est moi qui ai posé la question.
Ryan Lundy

Réponses:


195

Je n'ai vu cette erreur que sur Windows et cela semble vouloir dire que quelque chose a empêché git de modifier un fichier au moment où il a essayé d'appliquer un patch.

Windows tend à donner aux processus un accès exclusif aux fichiers quand cela ne devrait pas être vraiment nécessaire, dans le passé, les antivirus ont été une source de suspicion, mais je n'ai jamais prouvé cela de manière concluante.

La chose la plus simple à faire est probablement d'interrompre et de réessayer, en espérant que cela ne se produira pas la prochaine fois.

git rebase --abort

Vous pouvez essayer d'utiliser git applyet de savoir ce que commit git essayait réellement de faire avant de le faire, git rebase --continuemais en toute honnêteté, je ne recommanderais pas cela. La plupart du temps, j'ai vu cela essayé, il y a eu une chance meilleure que nulle que quelque chose soit accidentellement manqué ou foiré.


6
@ Kyralessa: Hmmm, avez-vous essayé de redémarrer? Si quelque chose verrouille ce fichier de manière persistante, après un redémarrage (ou quelque chose d'un peu moins drastique qui libère le fichier), vous devriez pouvoir git checkout -- previously-locked-filele sauvegarder et l'exécuter.
CB Bailey

51
Eh bien, je ne sais toujours pas exactement ce qui s'est passé, mais du mieux que je puisse dire, VS 2010 verrouillait le fichier (étrange car c'était un fichier doc .xml). Process Explorer n'a rien trouvé bloquant ce fichier, mais après avoir quitté VS, j'ai pu utiliser git checkoutpour récupérer le fichier ( git statusil a été supprimé), et maintenant tout est de retour tel qu'il était avant d'essayer de rebaser / écraser. Je devrais peut-être réessayer, même si je me sens un peu mal à l'aise à ce stade.
Ryan Lundy

3
Suivi, plusieurs lunes plus tard: je n'ai plus eu ce problème. Le rebasage a bien fonctionné, y compris même le rebasage interactif. Cela a dû être un problème momentané de verrouillage de fichier VS.
Ryan Lundy

49
La fermeture de Visual Studio 2010 l'a également corrigé
Trev

4
Atom verrouille également les fichiers. Le redémarrage l'a corrigé.
Augustin Bralley

653

Essayez de fermer tous les programmes dont le dossier est ouvert, tels que les éditeurs, les fenêtres de l'explorateur, les invites de commande et les programmes FTP. Cela résout toujours le problème pour moi sous Windows.


72
J'obtenais la même erreur. Je viens de fermer Visual Studio et tout a fonctionné.
jacobsimeon

6
J'ai fermé à peu près tout ce à quoi je pouvais penser avant de me souvenir du convertisseur WinLess LESS -> CSS caché en arrière-plan.
Michael Martin-Smucker

6
Visual Studio a verrouillé un package nuget lorsque j'ai essayé de fusionner. La fermeture de VS a fonctionné pour moi.
CodeHxr

7
La source la plus courante de cette erreur, que j'ai vue sous Windows, est Visual Studio bloquant les fichiers. Comme prescrit, fermez VS avant de changer de branche, de fusionner, etc.
longda

5
"Moi aussi" réponse pour Atom. Il semble verrouiller les fichiers et les répertoires; sa fermeture résout le problème.
ajm

277

Fermez simplement votre IDE (VISUAL STUDIO / ATOM, etc.). Cela peut fonctionner


1
Dans IntelliJ, l'arrêt du service Tomcat en cours d'exécution a fonctionné pour moi. Un peu plus facile que de redémarrer IDE.
Phil Carter

J'ai également eu une fenêtre Git Bash ouverte - qui a fonctionné pour moi.
Vince I

Tout IDE qui en vaut la peine ne devrait rien verrouiller dans un dépôt ... bravo !!
LightCC

Frappez ce problème après vous être enregistré dans une branche temporaire à l'aide d'Atom sous Windows 10. La fermeture et la réouverture d'Atom ont résolu le problème pour moi.
mickburkejnr

24

Quand je vois cela sur ma machine, c'est pire qu'un simple "certains processus ont le fichier ouvert". La propriété réelle du fichier est détournée au point où je (en tant qu'administrateur) ne peux y accéder qu'après le redémarrage.

Le plus proche que je peux dire, IIS fait partie du problème. Si je bascule entre deux branches principales qui nécessitent beaucoup de fichiers à modifier, git supprimera un fichier ou un répertoire (généralement des DLL) pendant qu'IIS essaie de faire quelque chose avec lui. À ce stade, le processus IIS écrase automatiquement le fichier sur le disque avec une version verrouillée et ne semble appartenir à personne.

Arrêter IIS à ce stade ne le fait pas. Le mieux que j'ai découvert est de redémarrer et n'oubliez pas d'arrêter IIS avant de changer dans les principales branches à l'avenir.

Je sais que cela ne répond pas vraiment à la question, mais pourrait être utile aux autres.


Salut, Mike ... nous avons exactement le même problème, mais il est sorti de nulle part. Nous avons utilisé le même processus sur de nombreux projets avec IIS en cours d'exécution, et nous n'avons jamais eu de problème. Un jour, cependant, cela commence à se produire ... déroutant et frustrant. En avez-vous appris plus depuis que vous avez écrit cela?
Ethan Brown

Merci pour la perspicacité de Mike - dans mon cas, en vérifiant une ancienne branche avec un projet ASP.NET MVC qui avait une URL de liaison différente de la branche précédente, Visual Studio puis IIS ont verrouillé certains fichiers du projet. L'arrêt du pool d'applications approprié dans IIS a supprimé le verrou.
fundead

IIS était aussi le coupable pour moi; lorsque cela apparaît, un rapide iisresetsemble libérer les verrous de fichiers.
alexm

J'ai trouvé que la même chose se produit avec OneDrive: changer de branche dans un référentiel stocké dans OneDrive le confond vraiment
CharlieB

Cela m'est également arrivé sur win10, nécessitant un redémarrage mais je n'ai pas testé la iisresetsolution.
qdread

17

Sous Windows, il peut s'agir d'un processus TortoiseGIT qui bloque ces fichiers. Ouvrez le gestionnaire de tâches et terminez le processus TGitCache.exe .


2
Bon à savoir, bien que dans mon cas, je n'utilise pas TortoiseGit; J'utilise simplement la ligne de commande.
Ryan Lundy

13

Je suis juste tombé sur ce fil de réponses - cette erreur est une erreur fausse. # Erreur: impossible de stat 'reddit / app / views / links': autorisation refusée

C'est tout ce que j'ai - en essayant de fusionner. J'ai lu quelques-unes des réponses, puis j'ai réalisé - tout ce que j'avais à faire était de fermer mon éditeur de code qui se trouve être Atom.

Une fois l'éditeur fermé - j'ai relancé "git merge" et boom, ça a marché.

Quelle erreur inutile :(


Merci! Vous ne verrez pas tous les jours la «bonne» réponse dans la liste. Je recommande que cela soit marqué comme la bonne réponse. Plutôt que d'interrompre l'opération en cours, il est logique de résoudre le vrai problème.
Nikhil Kuriakose

12

si vous utilisez vscode, supprimez le terminal et ouvrez-en un nouveau. sinon peut-être aussi fermer le terminal


C'était ça, ressemblait à un verrouillage de processus ou quelque chose
Mike Upjohn

10

Cela m'arrive parfois dans Windows

erreur: impossible de stat 'nom de fichier': autorisation refusée

Le plus souvent, j'ai plusieurs instances de bit bash ouvertes, et l'une des instances de git bash se trouve dans un répertoire qui n'existe pas dans la branche distante dont je tire.

La fermeture de toutes les instances de git bash sauf une résout le problème pour moi.


9

Si l'IDE que vous utilisez (au cas où vous en utilisez un) pourrait également gêner. C'est ce qui m'est arrivé lors de l'utilisation de QtCreator.


Ce fut le cas avec moi, en utilisant PhpStorm. Le redémarrage a corrigé l'erreur.
lancemonotone

7

L'utilisation de SourceTree dans Win 10 a résolu le problème en fermant l'éditeur Atom.

Erreur de reproduction:

  1. Dans la branche B, créez un fichier md, en utilisant Atom, éditez-le, enregistrez et validez.
  2. Basculez vers la branche A, déroulez de nouvelles validations depuis le serveur.
  3. Essayez de revenir en arrière, Opps, il est dit "erreur: impossible de stat 'fichier': autorisation refusée".

6

Cela peut également se produire lorsque vous utilisez SublimeText et que la fenêtre contextuelle vous demandant d'acheter le programme n'est pas fermée.


1
Je l'ai également obtenu avec Atom simplement en ouvrant l'arborescence du projet / fichier
Hal

1
Comme @Hal, mon problème était avec Atom. C'était parce qu'un dossier dans une branche n'était pas dans une autre branche. La fermeture d'Atom le corrigera, mais vous pouvez également réduire l'arborescence du projet (pour masquer le dossier), et cela fonctionne aussi.
jsalwen

6

Cela se produit souvent lorsque des logiciels / applications de prétraitement surveillent le projet, tels que Prepros ou Codekit. En outre, Atom et Sublime (et même Notepad ++) peuvent provoquer ce problème si un fichier du projet est en cours de modification.

Le moyen le plus simple de contourner le problème est de fermer tout ce qui a ouvert les fichiers du projet, de fusionner vos branches, puis de les rouvrir pour le rafraîchir. Cela évitera également tout problème où le programme n'est plus au courant des changements qui se sont produits, vous obligeant à actualiser le (s) projet (s) à la main.


1
ô homme! Je courais de l'orme en direct en arrière-plan. Cela m'a sauvé une tonne de maux de tête.
frostymarvelous

6

Si vous utilisez Webpack, arrêtez-le. Arrêtez également votre IDE. Devrait bien fonctionner après avoir fait ces choses.


4

J'avais un problème similaire. Mais c'était très simple à résoudre. Sur une machine Windows, mon explorateur de fichiers avait un dossier ouvert qui existait dans une branche mais pas dans l'autre que j'ai extrait. La fermeture de l'explorateur de fichiers a résolu le problème.


4

Je viens de l'avoir sous Win 7.

$ git stash pop error: impossible de stat 'parentFolder / subfolder': Autorisation refusée erreur: impossible stat 'parentFolder / subfolder': Autorisation refusée

Diagnostic:

1> Je suis allé dans le sous-dossier et il est là et je n'ai pas pu le supprimer!

2> Utilisez "Explorateur de processus" -> Rechercher -> Rechercher des poignées et des DLL -> mettez le nom du "sous-dossier" là-bas et recherchez.

Résultat: il s'avère que XMLSpy a ouvert l'un des fichiers XML, fermez XML Spy et essayez à nouveau de masquer la pop, cela fonctionne maintenant.


4

Cela m'est arrivé sous Windows lors du rebasage à l'intérieur du terminal intégré IntelliJ . J'ai remarqué que j'avais une instance de client Git bash fonctionnant en parallèle.

La fermeture de Git bash a résolu le problème.


2

Ma rencontre avec ce problème a été causée par mon éditeur, Intellij. Dans le cadre de ses contrôles de version internes, il avait parcouru et verrouillé tous les fichiers git cachés. (Pour diverses raisons, je n'utilisais pas le plugin git fourni avec Intellij ...)

J'ai donc ouvert une fenêtre DOS normale en tant qu'administrateur, changé pour le répertoire et exécuté

attrib -R /S

Cela a supprimé le verrou sur les fichiers et tout a fonctionné après cela et j'ai pu synchroniser mes modifications à l'aide du client Windows GitHub.


2

Je suis d'accord avec les réponses ci-dessus "Fermer Visual Studio".

Cependant, une étape supplémentaire que je devais faire même après avoir fermé Visual Studio était de tuer manuellement le processus Visual Studio "devenv.exe" dans l'Explorateur de tâches. Après avoir fait cela, j'ai pu à nouveau exécuter dans gitbash:

git pull

et l' erreur " Can't Stat Filename " a disparu. Cela est peut-être dû à une extension de Visual Studio qui maintient le processus ouvert plus longtemps même après la fermeture.


2

Je viens d'avoir ce problème. Le truc, c'est que si vous aviez ouvert un fichier qui a été supprimé \ remplacé après rebase (vous aviez une branche qui n'a plus ce fichier), le système git corrompt. J'ai donc fermé tous les fichiers ouverts, puis j'ai essayé de passer à la caisse sur une autre branche


2

Une solution alternative plutôt que de fermer toutes les applications qui pourraient verrouiller le répertoire comme à peu près toutes les autres réponses disent, serait d'utiliser un utilitaire qui déverrouillera les fichiers / répertoire sans tout fermer. (Je déteste avoir besoin de redémarrer Visual Studio)

LockHunter est celui que j'utilise: https://lockhunter.com/ Il y en a probablement d'autres aussi, mais celui-ci a très bien fonctionné pour moi.


1

Même problème sur Windows 10 64 bits, exécutant Git Bash version 2.9.0.windows1 en utilisant Atom comme mon éditeur.

Cela a fonctionné pour moi: j'ai ajouté le dossier du logiciel Git (pour moi, c'était C: \ Program Files \ Git) aux exclusions pour Windows Defender.

Après l'ajout de l'exclusion, git checkout 'file'a bien fonctionné.


1

Cette erreur peut également être due au fait que les fichiers sont toujours "verrouillés" en raison d'actions git antérieures. Cela a à voir avec le fonctionnement de la couche système de fichiers Windows. J'ai lu une fois une belle explication à ce sujet, mais je ne me souviens pas où.

Dans ce cas cependant, comme il s'agit essentiellement d'une condition de concurrence , tout ce que vous avez à faire est de poursuivre votre processus de rebase interrompu . Malheureusement, cela m'arrive tout le temps, alors j'ai écrit ce petit assistant dangereux pour continuer mes rebases:

#!/bin/sh

set -e

git checkout .
git clean -df
git rebase --continue

Si vous voulez être plus sûr, vous pouvez utiliser git rebase --edit-todopour vérifier si le prochain commit à appliquer est vraiment celui qui n'a pas été appliqué auparavant. Utilisez git clean -dnpour vous assurer de ne supprimer aucun fichier important.


1

Cela m'est arrivé dans Windows, lors de l'utilisation de photoshop: lorsque j'ai enregistré une image, puis que je suis passé à une branche (laissant photoshop avec l'image ouverte), j'ai eu l'erreur git. Fermez l'image dans Photoshop et réessayez



1

Tuer le processus w3wp.exe lié au référentiel a corrigé cela pour moi.


1

Dans mon cas, j'avais un serveur de développement webpack derrière.


0

J'ai eu cette erreur lorsque mon VS1013 était sur une branche ciblant 8.1 et j'essayais de commander une branche 8.0. J'avais besoin de revenir sur VS et de l'autoriser à UpdateAll. Ensuite, j'ai pu vérifier la branche 8.0 sans erreur.


0

J'étais également sur une machine Windows utilisant Git Shell lorsque j'ai rencontré la même erreur.

Cependant, à l'époque, j'avais plusieurs terminaux Git ouverts.

Le premier terminal a reçu l'erreur que vous avez signalée ci-dessus et l'autre terminal avait précédemment exécuté la grunt servecommande de terminal de yeoman (lié ci-dessous). Le deuxième terminal devait rester ouvert pour héberger une instance de serveur local.

L'arrêt de toutes les fenêtres de terminal exécutant des processus en cours peut entraîner la disparition de l'erreur.

C'est du moins ce qui a fonctionné pour moi. Après avoir fermé la deuxième fenêtre du terminal, je pouvais facilement extraire différentes branches et manipuler des fichiers.

Commande Grunt Serve - Yeoman.I / O
http://yeoman.io/learning/


0

Je viens de rencontrer ce problème. Aucune des réponses ici n'est parvenue à résoudre ce problème pour moi.

J'ai fini par être des paquets de pépites que j'ai ajoutés sur une branche qui, une fois revenue à la branche principale, semblait ne pas exister. Une fois que j'ai fait une fusion, cela dirait que newtonsoft ... xml ne pouvait pas stat. Je voudrais aller au fichier en question et l'ouvrir mais Windows a renvoyé une erreur en disant qu'il ne peut pas trouver le fichier (même si je le regardais bien)

Comment j'ai résolu cela était un clic droit supprimer le fichier (qui a fonctionné mais je ne pouvais pas l'ouvrir parce que Windows ne pouvait pas le trouver ???) et essayer de fusionner à nouveau et cela a résolu le problème.

Très étrange.

J'espère que cela aidera quelqu'un plus tard.


0

Je suis sorti de mon éditeur de texte qui accédait aux répertoires du projet, puis j'ai essayé de fusionner avec la branche principale et cela a fonctionné.

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.