374

I'm using git, and made a small commit followed by a large one. I decided to use git rebase to squash the two commits together before pushing them. (I've never done this before.)

So I did:

git rebase -i HEAD~2

This gave me my editor, where I chose to pick the earlier commit and squash the later one. When I saved, git said:

error: cannot stat 'filename': Permission denied

Could not apply sha1 for later commit... initial line of text for that commit

Now:

  • Neither commit appears when I do git log.
  • git status tells me I'm "Not currently on any branch."
  • One file is listed as modified and in the index, and two files are listed as untracked. My first commit had just one file (I think), and my second commit had a good dozen.

What happened!? How do I fix it?

Community
  • 1
  • 1
Ryan Lundy
  • 187,365
  • 35
  • 174
  • 206
  • 12
    Are you, by and chance, using git on windows? – CB Bailey May 11 '11 at 21:35
  • Yes. I run the commands in a DOS window. – Ryan Lundy May 11 '11 at 21:36
  • 2
    Are you running a virus checker? Sometimes poor quality virus checker programs cause issues like this. – Greg Hewgill May 11 '11 at 21:40
  • *shrug* Microsoft Forefront. But I've been using git for many weeks and never had a "cannot stat" problem before. Forefront isn't scanning at the moment. – Ryan Lundy May 11 '11 at 21:43
  • 55
    I had the issue with git checkout (so no abort possible as suggested by the accepted answer) but closing all my IDEs let me through. The second answer should be the accepted one – plus- Jan 04 '13 at 13:39
  • @plus- this should be the accepted answer IMO. I sort of want to downvote the question because the wrong answer has been accepted ... – Ian Grainger Aug 03 '17 at 16:08
  • 2
    @IanGrainger, the answer you're referring to was posted *eight months* after the accepted answer. Do I need to come 'round and visit all my questions every few months to potentially change accepted answers on all of them? The voting buttons are there for a reason. If the most-upvoted answer helps you more than the accepted answer, then use it. Who's stopping you? But I accepted the answer I did because it helped me, and I'm the one who asked the question. – Ryan Lundy Aug 03 '17 at 19:58
  • Most retarded, useless, meaningless error message I've ever seen – garryp Sep 15 '17 at 16:29
  • in my case it was a bug with vscode , checkout from braches reproduce this, file is simply a folder that belongs to another branch – moein rahimi Mar 09 '19 at 06:51
  • I am on Windows. Closing vscode did not not work for me. Had to restart the machine. – Gihanmu Aug 13 '20 at 05:43

34 Answers34

692

Try closing any programs that have the folder open, such as editors, explorer windows, command prompts, and FTP programs. This always fixes the issue for me on Windows.

culix
  • 8,979
  • 5
  • 31
  • 49
Cameron Wright
  • 7,021
  • 2
  • 11
  • 5
  • 1
    Ran into this on a merge. Apparently Gimp had a hold on a file which I had already closed. Closed Gimp itself and all's well. – Jerry May 01 '12 at 19:07
  • 79
    I was getting the same error. I just closed visual studio and everything worked. – jacobsimeon May 09 '12 at 16:45
  • had a similar issue. Has happened twice since renaming folders in my development branch. Exiting my editor fixes the issue. – Larry May 11 '12 at 11:10
  • 7
    I closed just about everything I could think of before I remembered the WinLess LESS -> CSS converter hiding in the background. – Michael Martin-Smucker Jun 13 '12 at 15:20
  • It was Github's Windows client for me. Closing it fixed the problem. Thanks! – Ates Goral Nov 05 '12 at 04:05
  • 7
    Visual Studio held a lock on a nuget package when I tried to merge. Closing VS worked for me. – CodeHxr Nov 27 '12 at 19:40
  • 8
    Most common source of this error, that I've seen on Windows, is Visual Studio locking up the files. As prescribed, close VS before switching branches, merging, etc. – longda Mar 20 '13 at 20:11
  • 1
    In my case, it was avast's Script Shield or Behavior Shield (not sure which, but definitely one of those two). Stopping them briefly solved the problem. – shovavnik Sep 26 '13 at 22:19
  • My issue was Visual Studio had a lock on the file. This should be the accepted answer – d48 Jul 24 '14 at 21:12
  • This should definitely be the accepted answer. Rebooted, everything worked. Could be either the editor (Sublime in this case), IIS, or SASS preprocessor, but something had files in use. – nickb Oct 21 '14 at 00:34
  • It was Visual Studio for me. No problems before, but it decided to hold onto a package file for me this time. – tekiegirl Nov 06 '14 at 12:16
  • Worked for me too - I stopped Apache and MySQL in XAMPP before pulling. – hatef May 15 '15 at 13:53
  • 7
    "Me too" answer for Atom. It seems to lock files and directories; closing it fixes the issue. – ajm Jul 21 '15 at 13:25
  • Had a server running in a shell file, closing this fixed it for me, thanks. – Daniel Lizik Sep 09 '16 at 15:06
  • Git will often dump the changes into the working directory when it fails to change a branch due to locked files. I often find myself performing `git reset --hard` (remove working dir changes) followed by `git clean -fd` (remove untracked files and directories) – Todd Nov 22 '17 at 12:34
  • 1
    I rebooted which amounts to closing your IDE ;).. also fixed it for me! – Pieterjan Spoelders Apr 11 '18 at 16:49
  • Closing Atom editor solved this for me on Windows 10 – PolarisTLX May 16 '19 at 16:55
  • 1
    In my case it was a PDF viewer that was blocking a file inside the folder git was trying to access. – mfru Aug 09 '19 at 07:57
  • 1
    I found that if Cygwin is open in a folder (like `tests`), and I want to merge a branch into master, I have to `cd ..` to the root directory and then perform the merge in Git Bash. – Edwin Pratt Aug 20 '19 at 13:57
  • For me, this was due to running the relevant application in Windows' Ubuntu terminal while switching branches in Git Bash. Normally, file changes are fine while the app is running due to live reload. However, it seems that when switching branches that would normally cause a folder deletion while something else has a lock on it, the ownership on the folder gets totally obliterated and the Windows user can't do anything. The folder that would have been deleted couldn't even be accessed, preventing any other action in Git that might involve that folder. Took me far too long to figure that out. – Chrysus Jan 05 '20 at 18:27
  • I kept closing apps I felt relevant and it got resolved – Shilpa Aug 25 '20 at 19:06
  • Closing some programs worked well for me while I was so worried that I could not retrieve those files. Thank you so much! – user710 Feb 05 '21 at 21:20
  • For me, a windows administrator permissions window had popped up in the background. Checking allow fixed the error – jaimedash Apr 12 '21 at 15:46
  • still find this useful in 2021! – GoFindTruth Apr 27 '21 at 14:58
303

Just close your IDE (VISUAL STUDIO/ATOM etc). It might work

ManJan
  • 3,773
  • 3
  • 18
  • 22
211

I've only ever seen this error on Windows and what it seems to mean is that something blocked git from modifying a file at the moment when it tried to a apply a patch.

Windows tends to give processes exclusive access to files when it shouldn't really be necessary, in the past virus checkers have been one source of suspicion but I've never proved this conclusively.

Probably the easiest thing to do is to abort and try again, hoping that it doesn't happen the next time.

git rebase --abort

You can attempt to use git apply and knowledge of what commit git was actually trying to do before doing a git rebase --continue but in all honesty I wouldn't recommend this. Most of the times I've seen this tried there's been a better than evens chance that something gets accidentally missed or messed up.

CB Bailey
  • 648,528
  • 94
  • 608
  • 638
  • 1
    When I try to abort, I get "error: unable to create file *same file it couldn't stat* (Permission denied)" and then "fatal: Could not reset index file to revision '*big long sha1*'. – Ryan Lundy May 11 '11 at 21:44
  • Although...it does look as though my commits are back, which is something I was worried might not happen. – Ryan Lundy May 11 '11 at 21:45
  • 7
    @Kyralessa: Hmmm, have you tried rebooting? If something is persistently locking that file then after a reboot (or something slightly less drastic that releases the file) you should be able to `git checkout -- previously-locked-file` and be back up and running. – CB Bailey May 11 '11 at 21:51
  • 57
    Well, I'm still not sure exactly what happened, but as best I can tell, VS 2010 was locking the file (odd because it was a .xml doc file). Process Explorer didn't find anything locking that file, but after I exited VS, I was able to use `git checkout` to get the file back (in `git status` it was deleted), and now everything is back as it was before I tried to rebase/squash. Perhaps I should try again, though I feel a bit queasy at this point. – Ryan Lundy May 11 '11 at 22:04
  • 3
    Follow-up, many moons later: I haven't had this problem again. Rebasing has worked fine, including even interactive rebasing. It must've been a momentary VS file-locking glitch. – Ryan Lundy Aug 03 '11 at 21:39
  • 55
    Closing Visual Studio 2010 fixed it for me too – Trev Jun 07 '12 at 17:46
  • 1
    This problem also occurs in Windows if Matlab has a directory in its path. (I encountered the problem after a git checkout where a directory on Matlab's path changed.) – Eponymous Nov 16 '12 at 17:06
  • Cameron White's answer should be the accepted answer - it's the better solution. – Scott Tesler May 31 '13 at 14:47
  • 1
    @ScottDavidTesler: It only addresses the initial cause; it doesn't address how to recover from the aborted state that Git left behind. – CB Bailey May 31 '13 at 14:52
  • Some things I've tried that may work: 1. close all programs that may have be reading the files in question 2. perform several smaller rebases instead of one big one. Sometimes Git seems to mess up and this approach may work – Steven Mar 26 '15 at 15:32
  • 1
    I don't think it's Windows giving processes exclusive access when it's not necessary, but rather processes asking for it when they don't need it. – Bart Read Jul 01 '15 at 09:51
  • 1
    For those who have done the new keygen generation and they still get an error if they try to push/checkout a branch etc, then try to close your IDE (Atom/VS etc). After scratching my head for an hour, I found out that my old key was perfectly fine and Atom IDE was the culprit. I simply restarted it and my problem was solved. – Ali Haider Sep 04 '16 at 02:20
  • Don't really need to run the rebase --abort – imbatman Sep 04 '16 at 07:38
  • 5
    Atom also apparently locks files. Restarting fixed it. – Augustin Bralley Nov 28 '17 at 07:15
  • fatal: No rebase in progress? – Francesco Dassisis Jul 28 '20 at 08:48
  • The same for me, closing VS2017 worked. I had a Folder Project open (Linux CMake) – 8znr Sep 09 '20 at 07:07
24

When I see this on my machine, it's worse than just a "some process has the file open". The actual ownership of the file gets jacked up to the point where I (running as administrator) can only access it after rebooting.

Nearest I can tell, IIS is part of the problem. If I switch between two major branches that require a lot of files to modify, git will delete a file or directory (usually DLLs) while IIS is trying to do something or another with it. At this point, the IIS process automatically overwrites the file on disk with a version that's locked and appears to be owned by nobody.

Stopping IIS at this point doesn't do it. Best I've found out to do is to reboot, and remember to stop IIS before changing across major branches in the future.

I know that doesn't really answer the question, but might be helpful to others.

Mike Ruhlin
  • 3,436
  • 2
  • 19
  • 30
  • Hi, Mike...we're having this exact same problem, but it came out of the blue. We've been using the same process on many projects with IIS running, and never had a problem. One day, though, it starts happening...baffling and frustrating. Have you learned any more since you wrote this? – Ethan Brown Apr 25 '12 at 21:40
  • Thanks for the insight Mike - in my case checking out an old branch with an ASP.NET MVC project which had a different binding URL to the previous branch caused Visual Studio then IIS to hold a lock on some files in the project. Stopping the appropriate apppool in IIS removed the lock. – fundead Jun 30 '15 at 22:38
  • IIS was the culprit for me as well; when this pops up a quick `iisreset` seems to release the file locks. – alexm Dec 28 '16 at 16:05
  • I've found that the same thing happens with OneDrive: switching branches in a repo stored in OneDrive really confuses it – CharlieB Nov 06 '17 at 13:15
  • This also happened to me on win10, requiring reboot but I didn't test the `iisreset` solution. – qdread Jan 07 '19 at 17:00
18

On Windows, it can be a TortoiseGIT process that blocks those files. Open task manager and end process TGitCache.exe.

romanlv
  • 1,282
  • 13
  • 15
17

if using vscode, kill terminal and open new one. else maybe close terminal too

Muhammed Moussa
  • 2,045
  • 19
  • 15
14

I just stumbled upon this thread of answers - this error is such a Bogus error.# error: cannot stat 'reddit/app/views/links': Permission denied

That's all I got - when trying to merge. I read a few of the answers and then came to the realization - all I had to do was close my code editor which happens to be Atom.

Once closing the editor - I ran "git merge" again and boom , it worked.

What a pointless error:(

imbatman
  • 460
  • 5
  • 14
  • Thank You! Not everyday will you see the 'right' answer down the list. I recommend this to be marked the right answer. Rather than aborting the current operation, makes sense to solve the real problem. – Nikhil Kuriakose Jul 13 '16 at 04:05
10

This happens to me in Windows occasionally

error: cannot stat 'filename': Permission denied

Most often I have multiple instance of bit bash open, and one of the git bash instances is in a directory that doesn't exist in the remote branch I'm pulling from.

Closing all but one instance of git bash solves the issue for me.

Crispy Ninja
  • 338
  • 4
  • 11
10

If the IDE you use(in case you use one) might have been getting in the way as well. That's what happened to me when using QtCreator.

rgngl
  • 4,901
  • 2
  • 28
  • 34
8

If you're running webpack shut it down. Shut down your IDE as well. Should work fine after doing those things.

KennethDale1
  • 93
  • 1
  • 3
7

Using SourceTree in Win 10, fixed the problem by closing Atom editor.

Error reproduce:

  1. In branch B, create a md file, using Atom edit it, save and commit.
  2. Switch to branch A, pull down new commits from server.
  3. Try Switch back, Opps, it says “error: cannot stat 'file': Permission denied”.
attolee
  • 532
  • 1
  • 6
  • 22
6

This can also happen when you're using SublimeText and the popup window asking you to buy the program is not closed.

ahnbizcad
  • 9,810
  • 9
  • 54
  • 77
  • 1
    Also got it with Atom just by having the project/file tree open – Hal Feb 24 '16 at 23:18
  • 1
    Like @Hal, my issue was with Atom. It was because a folder in one branch was not in another branch. Closing Atom will fix it, but you can also collapse the project tree (to hide the folder), and that works too. – jsalwen Sep 29 '16 at 18:34
6

This often happens when you have preprocessing software/applications watching the project, such as Prepros or Codekit. Also, Atom and Sublime (and even Notepad++) can cause this to happen if a file in the project is currently being edited.

The easiest way around the issue is to close whatever has the project files open, merge your branches, and then re-open them to refresh it. This will also avoid any problems where the program is no longer aware of any changes that have happened, forcing you to refresh the project(s) by hand.

Steven Ventimiglia
  • 709
  • 1
  • 9
  • 19
6

Happened to me on Windows while rebasing inside IntelliJ integrated terminal. I noticed that I had Git bash client instance running in parallel.

Closing Git bash solved the problem.

Louis
  • 1,409
  • 2
  • 20
  • 33
4

I had a similar problem. But it was very simple to resolve. On a Windows machine, my file explorer had a folder open that existed in one branch but not in the other I checked out. Closing the File explorer resolved the problem.

mmmdearte
  • 91
  • 2
4

I have just had this under Win 7.

$ git stash pop error: cannot stat 'parentFolder/subfolder': Permission denied error: cannot stat 'parentFolder/subfolder': Permission denied

Diagnosis:

1>I went to the subfolder and it's there and I couldn't delete it !

2>Use "process explorer" -> Find -> Find handles and Dlls -> put the "subfolder" name there and search.

Result: It turns out it's XMLSpy has opened one of the xml there, close XML Spy and try stash pop again, it's working now.

Gob00st
  • 5,279
  • 6
  • 40
  • 69
3

An alternate solution rather than closing all apps that might be locking the directory as just about every other answer says to do, would be to use a utility that will unlock the files/directory without closing everything. (I hate needing to restart Visual Studio)

LockHunter is the one that I use: https://lockhunter.com/ There are likely others out there as well, but this one has worked great for me.

HotN
  • 3,939
  • 3
  • 34
  • 47
3

Trying to close IDE such as Sublime, VS Code, Webstorm,... and close your programs that have the folder open such as CMD, Powershell, CMDer, Terminal,... will fix the issue.

Navy Flame
  • 497
  • 3
  • 15
2

My encounter with this problem was caused by my editor, Intellij. As part of its internal version controls, it had gone through and locked all hidden git files. (For various reasons, I was not using the git plugin that comes with Intellij...)

So I opened a normal dos window as Administrator, changed to the directory, and executed

attrib -R /S

That removed the lock on the files and everything worked after that and I could sync my changes using the GitHub windows client.

Perry Tew
  • 2,544
  • 3
  • 19
  • 25
2

I agree with the above "Close Visual Studio" answers.

However, an additional step I had to do even after I'd closed Visual Studio was to manually kill the "devenv.exe" Visual Studio process in Task Explorer. After I had done this I was able to again run in gitbash:

git pull

and the "cannot stat filename" error disappeared. It is perhaps due to a Visual Studio extension keeping the process open for longer even after closing.

ladygargar
  • 567
  • 9
  • 13
2

I've just had this problem. The thing is - if you had opened file, that was removed\replaced after rebase (you had a branch which doesn't have a this file anymore), the git-system corrupts. So i closed all opened files and then tryied to checkout on some other branch

BlondinkaBrain
  • 131
  • 1
  • 5
1

Same issue on Windows 10 64 Bit, running Git Bash version 2.9.0.windows1 Using Atom as my editor.

This worked for me: I added the Git software folder (for me, this was C:\Program Files\Git) to the exclusions for Windows Defender.

After the exclusion was added, git checkout 'file' worked fine.

1

This error can also be caused by the fact that files are still "locked" because of prior git actions. It has to do with how the Windows filesystem layer works. I once read a nice explanation on this, but I can't remember where.

In that case however, since it is basically a race condition, all you have to do is continue your interrupted rebase process. Unfortunately this happens to me all the time, so I wrote this little dangerous helper to keep my rebases going:

#!/bin/sh

set -e

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

If you want to be extra sure, you can use git rebase --edit-todo to check if the next commit to be applied is really the one that failed to be applied before. Use git clean -dn to make sure you do not delete any important files.

raphinesse
  • 13,873
  • 4
  • 33
  • 44
1

Happened to me when in windows, when using photoshop: When I saved an image and then switched to a branch (leaving photoshop with the image opened) i got the git error. Close the image in photoshop and retry

pscheit
  • 2,136
  • 21
  • 25
1

If you have the Meld merge tool open, close that. It blocks the file overwriting.

user2441511
  • 10,816
  • 3
  • 18
  • 47
1

Killing the w3wp.exe process related to the repository fixed this for me.

Ric
  • 643
  • 2
  • 10
  • 19
1

In my case, I had a webpack dev server running behind.

Charith
  • 2,640
  • 2
  • 19
  • 24
0

I got this error when my VS1013 was on a branch targeting 8.1 and I was trying to checkout a 8.0 branch. I needed to tab back to VS and allow it to UpdateAll. Then I could checkout the 8.0 branch without error.

0

I was also on a Windows machine using Git Shell when I encountered the same error.

However, at the time I had multiple Git terminals open.

The first terminal received the error you posted about above and the other terminal had previously ran the grunt serve terminal command from yeoman (linked below). The second terminal needed to remain open to host a local server instance.

Shutting down all terminal windows running ongoing processes can cause the error to go away.

At least that's what worked for me. After I shut down the second terminal window, I could easily checkout different branches and manipulate files.

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

Shawesome
  • 55
  • 11
0

I just ran into this issue. Non of the answers here happened to solve this for me.

Ended up being nuget packages I added on a branch that, once switched back to master branch, seemed to not exist. Once I did a merge it would say newtonsoft...xml could not stat. I would go to the file in question and open it but Windows threw an error back saying it can't find the file (even though I was looking right at it)

How I solved this was right click delete the file (which worked but I couldnt open it because windows couldnt find it???) and try to merge again and it solved the problem.

Very strange.

Hope this helps someone later.

TheNoob
  • 767
  • 2
  • 9
  • 24
0

I exited from my text editor that was accessing the project directories, then tried merging to the master branch and it worked.

PudparK
  • 111
  • 1
  • 13
0

Same problem but using SourceTree (or any other git client). I'm adding my answer as none of the answers correspond to my case.

Changing the branch from "develop" to "main" changes the actual files and subfolders of your local folder. It can happen that a folder that didn't exist in the "master" are not completely erased and windows believe you only lost your access rights (even if you're the admin). When merging from main to develop, the git client tries to access the folder. Without access rights, it returns the mentioned error.

  • Switching from one branch to the latest can fix the problem, and then back to master (double check if the folders/files are actually locally deleted).
  • Closing the client and/or your editor does not fix the problem!
  • Reboot helps but is a waste of time (IMHO)
Wli
  • 852
  • 6
  • 23
0

In my case the file is a shell script (*.sh file) meant to deploy our project to a local development server, for my developers.

The shell script should work consistently and may be updated; so I tracked it in the same Git project as the code which the script is meant to deploy.

The shell script runs one executable, and then allows that executable to run; so the script is still running; so my shell still has the script open; so it's locked.

I Ctrl+C'd to kill the script (so now my local dev server is no longer accessible), now I can checkout freely.

The Red Pea
  • 12,346
  • 12
  • 77
  • 112
-1

We resolved permission issues by right-clicking sh.exe in Program Files and by setting "Run as Administrator" in the Security tab.

o_o
  • 928
  • 1
  • 8
  • 14