0

Whenever I checkout a branch on my git repository that is old enough to not contain a recently added folder (thus causing git to try and delete the folder), the folder gets locked.

For example, I am working on a project that involves a couple of different modules. I was on the 'cases' branch, which had added files to a new directory ('[root]\src\app\data\cases'). I then checked out the 'chat' branch, which was old enough that it did not contain this directory. No error message occurred during the processes, but trying to navigate to this directory produces the following message (given as a Windows error dialog box):

Location is not available

[root]\src\app\data\cases is not accessible.

Access is denied.

The folder is definitely there, as it shows up in Explorer. Also, gulp refuses to start when the directory is present, citing the following error:

Error: EPERM: operation not permitted, scandir '[root]\src\app\data\cases'

I have tried updating to the latest version of git, and am now running 2.7.3.windows.1. I have a 64-bit Windows 10 laptop. While I would very much like to resolve this issue, restarting the computer does fix it. This is a possible workaround, although that does mean minutes of time lost each time I checkout with a new folder (there is no issue if the current directory has no new folders compared with the directory to be checked out).

Thanks in advance for whatever advice you can give.

alroc
  • 27,574
  • 6
  • 51
  • 97
Matthew Pull
  • 41
  • 1
  • 3
  • You're checking out a branch that doesn't contain a directory and then you're trying to access said directory, even though Git states it's not there in that branch. So what's your question here? Also, why isn't the directory there (aside from the branch being old)? Is it for a set reason as part of developing a feature or have you just not rebased the branch to line up with the parent branch? – Harmelodic Mar 17 '16 at 13:25
  • The problem is _not_ that the directory is not there, but rather that it **still is**. Git is (instead of deleting the directory) leaving it inaccessible. The directory is still there, and applications are still seeing it. I do not want the directory to be there, as that branch should not contain it. – Matthew Pull Mar 17 '16 at 13:40
  • [This answer](https://answers.atlassian.com/questions/329442/windows-permission-denied-on-switching-branches) seems to show that some (don't know which) applications that are open that talk to Git don't like to let go of things like directories when you change to an older branch. Solution was to close all applications that could possibly talk to Git (IDE, Git manager, File Explorer) and via command line, change branch. HTH. – Harmelodic Mar 17 '16 at 13:47
  • @Harmelodic I'll try to close everything down next time I change branches. I guess that it could be gulp, which is constantly monitoring the directory for changes, that is messing things up, so I'll definitely try stopping it next time. – Matthew Pull Mar 17 '16 at 13:51
  • Cool, update this question with your solution as an answer if it works or you find another work around! – Harmelodic Mar 17 '16 at 13:52
  • If it's not gulp, try one of the solutions in this ServerFault question to see what has a handle open to the directory: http://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows – Michael Burr Mar 17 '16 at 13:56
  • @Harmelodic Unfortunately stopping gulp has not fixed the issue. I tried Michael's suggestion as well, but nothing seemed to be using the directory at the time. I've tried a myriad of fixes on different forums to regain permissions to the directory, to no avail. The only solution that has worked for me is to restart the computer each time I checkout a directory that would case a folder to be removed. – Matthew Pull Mar 17 '16 at 15:28
  • @MatthewPull Or you could restructure your development/Git flow and rebase your old branches to include the newer code and then merge them. Really, you should only open a branch to develop a feature or fix a bug and then merge it with the parent branch once it's done. Don't leave branches open for a long time because then these issues occur and you'll be dealing with out of date code. But I understand you might have a complex Git flow that forces this sort of thing to happen. – Harmelodic Mar 17 '16 at 15:33
  • @Harmelodic Yeah, the 'cases' branch is developing a new feature (Case Management) that won't be ready for a few weeks. However, I have been told to launch the web app before then, with the Case Management feature to be added later. There is a 'dev' branch which is what will be bug-checked then released, and a 'chat' branch which is where I am working on the existing module that will be launched before Case Management. Therefore I cannot (unfortunately) merge 'cases' into either 'chat' or 'dev'. – Matthew Pull Mar 17 '16 at 15:37
  • In which case, either rebase `cases` to update the code, if you can. Or if no one is currently developing it and won't be for a while, checkout `cases`, take a copy of and archive `git diff dev...` (assuming `dev` is the parent branch to `cases`), then delete branch `cases`, then when you come to develop `cases` again, use the copy of the `git diff` as a reference as to what development needs to be done. That way you will be developing on top of up-to-date code with a reference of how you were initially going to develop `cases`. – Harmelodic Mar 17 '16 at 15:57
  • See [here](http://stackoverflow.com/questions/6913263/is-there-a-way-to-see-all-changed-files-on-a-branch-in-git) for what `git diff dev...` does. – Harmelodic Mar 17 '16 at 15:59
  • @Harmelodic Thanks for the suggestions. `chat` is still being worked on daily, as it needs some tweaks prior to being launched in a week or so (before `cases` is anywhere near done). I basically just need to be able to switch between the branches multiple times a day without having to restart each time I go back to `chat` (`cases` checks out without an issue). As `chat` will be launched before `cases` is done, I cannot incorporate any changes from `cases` into it. The `chat` branch cannot have any idea that `cases` exists. Changes from `chat` are merged into `cases` fairly regularly, however. – Matthew Pull Mar 17 '16 at 16:08

0 Answers0