git rebase: "erreur: impossible de stat 'fichier': autorisation refusée"
J'utilise git, et j'ai fait un petit commit suivi d'un gros. J'ai décidé d'utiliser git rebase pour écraser les deux commits avant de les pousser. (Je n'ai jamais fait cela auparavant.)
Alors j'ai fait:
git rebase -i HEAD~2
Cela m'a donné mon éditeur, où j'ai choisi de choisir le plus tôt commit et d'écraser le plus tard. Quand j'ai sauvé, git a dit:
erreur: impossible de stat ' nom du fichier ': autorisation refusée
Impossible d'appliquer sha1 pour une validation ultérieure ... la ligne de texte initiale de cette validation
À présent:
- Ni commit n'apparaît quand je fais
git log. git statusme dit que je ne suis "pas 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 fichier (je pense) et mon second commit en avait une bonne douzaine.
Qu'est-il arrivé!? Comment je le répare?
Je n'ai jamais vu que cette erreur sous Windows et cela semble vouloir dire que quelque chose a empêché git de modifier un fichier au moment où il essayait d'appliquer un correctif.
Windows tend à donner aux processus un accès exclusif aux fichiers lorsque cela ne devrait pas être vraiment nécessaire. Dans le passé, les vérificateurs de virus étaient une source de suspicion, mais je ne l'ai jamais prouvé de manière concluante.
La chose la plus facile à faire est probablement d’avorter et de réessayer, en espérant que cela ne se produise pas la prochaine fois.
git rebase --abort
Vous pouvez essayer d'utiliser git apply et connaître ce que commit git essayait de faire avant de faire un git rebase --continue mais, en toute honnêteté, je ne le recommanderais pas. La plupart du temps, j'ai vu cela essayé, il y avait plus de chances que quelque chose soit oublié ou endommagé par inadvertance.
Essayez de fermer tous les programmes dont le dossier est ouvert, tels que les éditeurs, les fenêtres Explorer, les invites de commande et les programmes FTP. Cela corrige toujours le problème pour moi sous Windows.
Fermez simplement votre IDE (VISUAL STUDIO/ATOM, etc.). Cela peut fonctionner
Quand je vois cela sur ma machine, c'est pire qu'un "un processus a le fichier ouvert". La propriété réelle du fichier est bloquée jusqu'au point où je (fonctionnant en tant qu'administrateur) ne peut y accéder qu'après le redémarrage.
Au plus près, je peux dire, IIS fait partie du problème. Si je permute entre deux branches principales nécessitant beaucoup de fichiers à modifier, git supprimera un fichier ou un répertoire (généralement des DLL) pendant que IIS essaie de faire quelque chose ou d'autre avec. À ce stade, le processus IIS écrase automatiquement le fichier sur le disque avec une version verrouillée qui semble n'appartenir à personne.
Arrêter IIS à ce stade ne le fait pas. Le mieux que j’ai appris à faire est de redémarrer et d’arrêter IIS avant de passer d’une branche à l’autre.
Je sais que cela ne répond pas vraiment à la question, mais pourrait être utile aux autres.
Je suis tombé par hasard sur ce fil de réponses - cette erreur est une telle erreur fictive.
C'est tout ce que j'ai - en essayant de fusionner. J'ai lu quelques-unes des réponses, puis je me suis rendu compte que 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 lancé à nouveau "git merge" et ça a fonctionné.
Quelle erreur inutile :(
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 .
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.
Si le IDE que vous utilisez (au cas où vous en utilisiez un) aurait peut-être gêné également. C'est ce qui m'est arrivé lorsque j'utilisais QtCreator.
Cela se produit souvent lorsque des logiciels/applications de prétraitement surveillent le projet, tels que Prepros ou Codekit. Atom et Sublime (et même Notepad ++) peuvent également provoquer ce problème si un fichier du projet est en cours d'édition.
Le moyen le plus simple de résoudre le problème consiste à fermer tout ce qui a ouvert les fichiers de projet, à fusionner vos branches, puis à les rouvrir pour les actualiser. Cela évitera également tout problème lorsque le programme ne sera plus au courant des changements survenus, vous obligeant à actualiser le (s) projet (s) à la main.
Cela m'arrive de temps en temps dans Windows
erreur: impossible de stat 'nom de fichier': autorisation refusée
La plupart du temps, plusieurs instances de bit bash sont ouvertes, et l'une des instances de git bash se trouve dans un répertoire qui n'existe pas dans la branche distante d'où je tire.
Fermer tout sauf une instance de git bash résout le problème pour moi.
Je viens d'avoir cela sous Win 7.
$ git stash pop erreur: ne peut pas stat 'dossier/sous-dossier parent': autorisation refusée erreur: ne peut pas stat 'dossier/sous-dossier parent': permission refusée
Diagnostic:
1> Je suis allé dans le sous-dossier et c'est là et je ne pouvais pas le supprimer!
2> Utilisez "Process Explorer" -> Rechercher -> Rechercher les poignées et les Dll -> mettez le nom du "sous-dossier" et faites une recherche.
Résultat: il s'avère que XMLSpy a ouvert l'un des fichiers xml, ferme XML Spy et essayez à nouveau stash pop, cela fonctionne maintenant.
Utilisation de SourceTree dans Win 10, corrige le problème en fermant l’éditeur Atom.
Erreur reproduire:
- Dans la branche B, créez un fichier md, en utilisant Atom, modifiez-le, enregistrez-le et validez-le.
- Basculez vers la branche A, déroulez les nouveaux commits du serveur.
- Essayez de basculer en arrière, Opps, il dit "erreur: impossible de stat 'fichier': autorisation refusée".
J'avais un problème similaire. Mais c'était très simple à résoudre. Sur une machine Windows, l’explorateur de fichiers avait un dossier ouvert qui existait dans une branche mais pas dans l’autre que j’ai emprunté. Fermer l’explorateur de fichiers a résolu le problème.
si vous utilisez vscode, tuez le terminal et ouvrez-en un nouveau. sinon peut-être fermer le terminal aussi
Je viens d'avoir ce problème. Le problème est que si vous aviez ouvert un fichier qui avait été supprimé\remplacé après une nouvelle base (vous aviez une branche qui n’a plus ce fichier), le système git est corrompu. J'ai donc fermé tous les fichiers ouverts, puis j'ai essayé de passer à la caisse sur une autre branche.
Je suis d'accord avec les réponses "Fermer Visual Studio" ci-dessus.
Cependant, une étape supplémentaire que je devais faire même après la fermeture de Visual Studio consistait à manuellement tuer le "devenv.exe" Processus Visual Studio dans l’Explorateur de tâches . Après cela, J'ai été capable de courir à nouveau 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 sa fermeture.
Ma rencontre avec ce problème a été provoquée par mon éditeur, Intellij. Dans le cadre de ses contrôles de version internes, il avait examiné 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, j'ai changé de 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.
Cette erreur peut également être causée par le fait que les fichiers sont toujours "verrouillés" en raison des actions précédentes de git. Cela concerne le fonctionnement de la couche de système de fichiers Windows. J'ai lu une fois une bonne explication à ce sujet, mais je ne me souviens plus où.
Dans ce cas cependant, puisqu'il s'agit essentiellement d'une condition de concurrence critique, tout ce que vous avez à faire est de poursuivre votre processus de rebasement interrompu. Malheureusement, cela m’arrive tout le temps, j’ai donc écrit cette petite aide dangereuse pour que mes reproches se poursuivent:
#!/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-todo pour vérifier si le prochain commit à appliquer est vraiment celui qui a déjà été appliqué auparavant. Utilisez git clean -dn pour vous assurer de ne supprimer aucun fichier important.
Même problème sous Windows 10 64 bits, exécutant Git Bash version 2.9.0.windows1 Utilisation d’Atom comme éditeur.
Cela a fonctionné pour moi: j'ai ajouté le dossier du logiciel Git (pour moi, il s'agissait de C:\Program Files\Git) aux exclusions de Windows Defender.
Une fois l'exclusion ajoutée, git checkout 'file' a bien fonctionné.
Si vous utilisez webpack, fermez-le. Éteignez également votre IDE. Devrait bien fonctionner après avoir fait ces choses.
Ce qui m'est arrivé quand dans Windows, lorsque j'utilisais Photoshop: Lorsque j'ai sauvegardé une image, puis que je suis passée à une branche (laissant Photoshop ouvert avec l'image ouverte), l'erreur s'est produite. Fermez l'image dans photoshop et réessayez.
Tuer le processus w3wp.exe lié au référentiel a corrigé cela pour moi.
Si vous avez ouvert l'outil de fusion Meld , fermez-le. Il bloque l'écrasement du fichier.
Cela m’est arrivé sous Windows lors de la refonte du terminal intégré IntelliJ . J'ai remarqué que j’avais une instance client Git bash exécutée en parallèle.
Fermer Git bash a résolu le problème.
Une solution alternative, plutôt que de fermer toutes les applications susceptibles de verrouiller le répertoire comme le ferait presque toute autre réponse, consiste à utiliser un utilitaire qui déverrouille le fichier/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 également, mais celui-ci a très bien fonctionné pour moi.
Je viens de rencontrer ce problème. Aucune des réponses ici ne s'est avérée résoudre ce problème pour moi.
En fin de compte, ce sont des paquets de nugets que j’ai ajoutés sur une branche qui, une fois passée en branche principale, semblait ne pas exister. Une fois que j'ai fait une fusion, il dirait que newtonsoft ... xml ne pouvait pas stat. J'allais au fichier en question et l'ouvrais 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 le problème: cliquez avec le bouton droit de la souris pour supprimer le fichier (ce qui a fonctionné, mais je ne pouvais pas l'ouvrir car Windows ne pouvait pas le trouver ???) et essayer de fusionner à nouveau pour résoudre le problème.
Très étrange.
J'espère que cela aidera quelqu'un plus tard.
J'étais également sur une machine Windows utilisant Git Shell lorsque j'ai rencontré la même erreur.
Cependant, à l'époque, plusieurs terminaux Git étaient 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 commande de terminal grunt serve depuis yeoman (lien ci-dessous). Le deuxième terminal devait rester ouvert pour héberger une instance de serveur local.
La fermeture de toutes les fenêtres de terminal exécutant des processus en cours peut entraîner la disparition de l'erreur.
Au moins c'est 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 de service Grunt - Yeoman.I/O
http://yeoman.io/learning/
Nous avons résolu les problèmes d'autorisation en cliquant avec le bouton droit de la souris sur sh.exe dans Program Files et en définissant "Exécuter en tant qu'administrateur" dans l'onglet Sécurité.
Dans mon cas, le fichier est un script Shell (fichier *.sh) destiné à déployer notre projet sur un serveur de développement local, pour mes développeurs.
Le script shell doit fonctionner de manière cohérente et peut être mis à jour. Je l'ai donc suivi dans le même projet Git que le code que le script est censé déployer.
Le script shell exécute un fichier exécutable, puis autorise son exécution. donc le script est toujours en cours d'exécution; alors mon shell a toujours le script ouvert; donc c'est verrouillé.
Je Ctrl+C 'pour tuer le script (donc maintenant mon serveur de dev local n'est plus accessible), maintenant je peux passer ma commande librement.
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é.
Dans mon cas, j'ai eu un serveur de développement Webpack derrière.
Même problème mais en utilisant SourceTree (ou tout autre client git). J'ajoute ma réponse car aucune des réponses ne correspond à mon cas.
Si vous modifiez la branche de "develop" à "principale", les fichiers et sous-dossiers de votre dossier local sont modifiés. Il peut arriver qu'un dossier qui n'existait pas dans le "maître" ne soit pas complètement effacé et Windows pense que vous n'avez perdu que vos droits d'accès (même si vous êtes l'administrateur). Lors de la fusion de main pour développer, le client git tente d’accéder au dossier. Sans droits d'accès, l'erreur renvoyée est renvoyée.
- Le passage d'une branche à une autre peut résoudre le problème, puis revenir au maître (vérifiez si les dossiers/fichiers sont réellement supprimés localement).
- Fermer le client et/ou votre éditeur ne résout pas le problème!
- Reboot aide mais est une perte de temps (IMHO)
J'ai eu cette erreur quand mon VS1013 était sur une branche ciblant 8.1 et j'essayais de commander une branche 8.0. Je devais revenir à VS et lui permettre de UpdateAll. Ensuite, j'ai pu vérifier la branche 8.0 sans erreur.