Skip to content

git bash: folder locks not released #335

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
liayn opened this issue Aug 29, 2015 · 13 comments
Closed

git bash: folder locks not released #335

liayn opened this issue Aug 29, 2015 · 13 comments
Labels

Comments

@liayn
Copy link

liayn commented Aug 29, 2015

Version: 2.5.0

Steps to reproduce:

  1. Open gitbash in a repository
  2. cd into some subfolder
  3. change out of it again
  4. try to delete/move that subfolder in Explorer
  5. Error: "File or Folder still in use"
  6. Close gitbash
  7. try again
  8. works.

Expected:
Step 4 should be successful already.

@SoboLAN
Copy link

SoboLAN commented Aug 29, 2015

Do you have TortoiseGit installed or any other visual Git tool that attaches to explorer and/or adds context options in the "right-click" menu ?

@liayn
Copy link
Author

liayn commented Aug 29, 2015

Yes, TortoiseGit is installed, but not used for the case above.

@maoueh
Copy link

maoueh commented Aug 30, 2015

Use procexp.exe when you get the File or Folder still in use, then Find > Find handle or DLL... then type folder currently locked, check what process holds the directory in question and report back.

@liayn
Copy link
Author

liayn commented Aug 30, 2015

For whatever reason I can't reproduce this today anymore... weird, I could do so yesterday.

Closing this for now. If I run into it again, I'll come back with more details.
Thanks for you time guys, appreciate it!

@liayn liayn closed this as completed Aug 30, 2015
@AlexTelon
Copy link

AlexTelon commented Nov 20, 2018

I have this same issue.

  1. create folder tmp
  2. open git bash from right-click menu
  3. cd .. # I am now outside the tmp folder
  4. try to delete tmp
  5. Error "Folder in Use"
  6. Close git bash
  7. Try again
  8. Works

The difference is that I used the right-click menu and this does not have to be in a git repo. I created a tmp folder on my desktop just now and still got the issue.

Used procexp.exe as @maoueh suggested and it is indeed git bash that locks it.
image

@liayn
Copy link
Author

liayn commented Nov 20, 2018

I had the same issue a few days ago again. Thanks for bringing this up again.

@liayn liayn reopened this Nov 20, 2018
@dscho
Copy link
Member

dscho commented Nov 28, 2018

I think this is by design. git-bash.exe spawns a MinTTY which in turn spawns a bash.exe, and only that bash.exe's working directory can be changed. The other two processes need to wait for bash.exe (and then mintty.exe) to be done.

So if you gentle people have any idea how this wish can be fulfilled, let's hear it. Otherwise we'll have to close this as "Can't fix".

@dscho dscho added the question label Nov 28, 2018
@liayn
Copy link
Author

liayn commented Nov 28, 2018

I think this is by design.

In this context I would rephrase that to "this is by mis-design" then to be honest. But I fully understand in this regard that this is not fixable for you.

@dscho
Copy link
Member

dscho commented Nov 28, 2018

In this context I would rephrase that to "this is by mis-design" then to be honest.

Sure, let's just talk down the work of others, without adding any effort. Is that how you want this discussion to end?

Alternatively, you could either come up with a better design and implement it, or show some grace.

@dscho dscho closed this as completed Nov 28, 2018
@liayn
Copy link
Author

liayn commented Nov 28, 2018

Sure, let's just talk down the work of others, without adding any effort. Is that how you want this discussion to end?

Oh dear, that indeed came out totally wrong! I didn't except that anyone would interpret my writing that way. Sorry for that.

I'm for sure not somebody who does not value work of others. (Well I'm quite involved in open source stuff, so I know the pain.) It was just that your sentence was about justifying an "end-user" inconvenience with a technical reason.
In this very case I'm pretty sure that this has nothing to do with how it was designed, it's rather a side-effect of how it is (or it rather has to be) designed currently.

I fully understand that and I'm neither angry or sad or upset or anything in this regard. It' an inconvenience, not nice, but not crucial.

Just to repeat it here. I do not and did not blame anybody, I simply negated your sentence.
I do not know who exactly built what and I'm very thankful for having a working git on windows.
(I also value your personal support @dscho a lot, which I needed some months ago, and your help was very appreciated.)

Regarding the problem: No, I don't have a better idea how we could capture a cd command and inherit the cwd up to the top-level process.
Acceptable resolution for me: Closing this due to being unfixable without major effort of rewriting the whole stuff. :-)

@dscho
Copy link
Member

dscho commented Nov 29, 2018

how we could capture a cd command and inherit the cwd up to the top-level process.

Would that not break the MinTTY promise that Alt+F2 clones the current window with the same working directory that the original was started from?

@liayn
Copy link
Author

liayn commented Nov 29, 2018

I have to admit that I don't know MinTTY and the inner workings. I didn't even know that shortcut, nor did I ever have the usecase you described for that shortcut.

@dscho
Copy link
Member

dscho commented Nov 29, 2018

I didn't even know that shortcut

One of the perks of taking care of this here bug tracker is that I am made aware of many features I had not even suspected to exist, including the Alt+F2 feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants