Problem with git gc because of TGitCache.exe

[GoogleCodeExporter]

I am using msys git with TortoiseGit.
Whenever I am trying to open up Git GUI, it asks me if I want to compress the 
repository. I say "yes", because I don't want to get nagged again.

Although the compressing is done successfully, it ends with the following 
messages:

rm: cannot unlink `pack-1a1ea987c6b5aecc77548d81ed6ea5a39c58a970.pack': 
Permission denied
rm: cannot unlink `pack-1a1ea987c6b5aecc77548d81ed6ea5a39c58a970.idx': 
Permission denied

So, if I open Git GUI next time, again I get the dialog. 

I have seen using "unlocker" tool that TGitCache.exe is hold the lock to those 
files. How can I get rid of it?

What steps will reproduce the problem?
1. Install both Tortoise Git and msys git.
2. Open Git Gui in a repository where compressing needs to be done.
2. Press "Yes" in the confirmation box.
3. Compressing will be successful will fail with those above messages.

What is the expected output? What do you see instead?
It should just compress.

What version of the product are you using? On what operating system?
TortoiseGit 1.4.4.0 
git version 1.7.0.2.msysgit.0 
Windows 7

Please provide any additional information below.
At least please tell me is there any way to tell Tortoise Git to not to cache, 
so that TGitCache never starts?

Original issue reported on code.google.com by ruj.sa...@gmail.com on 8 Jul 2010 at 7:49

[GoogleCodeExporter]

1.4.4 have this problem. 1.5.2 fix it

Original comment by lzn...@gmail.com on 8 Jul 2010 at 7:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Still facing this problem with 1.5.2. Pls see attachments.

Original comment by ruj.sa...@gmail.com on 13 Jul 2010 at 10:42

Attachments:

• tortoiseVersion.PNG
• git.PNG

[GoogleCodeExporter]

you can disable icon over lay at setting dialog, tgitcache.exe will no launch.
can you check gitdll.dll version?

Original comment by lzn...@gmail.com on 13 Jul 2010 at 10:48

[GoogleCodeExporter]

Okay. That works. I've also noticed if I set it to "shell extended" then also 
tgitcache.exe is not launching. Will that work too?

gitdll version says 1.5.2. Please see attachment.

Original comment by ruj.sa...@gmail.com on 14 Jul 2010 at 4:47

Attachments:

• gitdll.PNG

[GoogleCodeExporter]

only "default" launch tgitcache.exe.
"shell extended" will slow down explorer if there are big repository. If there 
are crash at fetch overlay status, explore will crash.

Original comment by lzn...@gmail.com on 14 Jul 2010 at 4:57

[GoogleCodeExporter]

Original comment by lzn...@gmail.com on 9 Oct 2010 at 1:54

• Changed state: Discuss

[GoogleCodeExporter]

TGitCache should add support for polling instead of watching. This way it will 
not have to keep handle open.

Original comment by mwisnicki@gmail.com on 30 Oct 2010 at 8:51

[GoogleCodeExporter]

can you try 
http://tortoisegit.googlecode.com/issues/attachment?aid=4377645790915445353&name
=TGitCache-64bit.zip&token=6da61248e3226dd8561f59dc20ec39fe

Original comment by lzn...@gmail.com on 13 Mar 2011 at 4:42

[GoogleCodeExporter]

http://tortoisegit.googlecode.com/issues/attachment?aid=441987313904990145&name=
TGitCache.zip&token=13c30aa6a7830725aa3c92c4b5656114

Original comment by lzn...@gmail.com on 13 Mar 2011 at 4:42

[GoogleCodeExporter]

With new TGitCache(64-bit) I have so far been unable to cause any file 
operation to fail.
Also it seems that status overlays are computed faster and now finally correct 
(previously they were sometimes wrong).
Great work!

BTW. Are those changes also applicable to TortoiseSVN ? I have similar problems 
with TSVNCache sometimes.

Original comment by mwisnicki@gmail.com on 13 Mar 2011 at 11:37

[GoogleCodeExporter]

I mark this issue as fix. if you meet this problem again, reopen again.

I have not idea about TortoiseSVN. 

Original comment by lzn...@gmail.com on 14 Mar 2011 at 1:31

• Changed state: Fixed

[GoogleCodeExporter]

I just had this problem again but I am unable to easily reproduce it. So it is 
still there :(

Original comment by mwisnicki@gmail.com on 19 Mar 2011 at 4:06

[GoogleCodeExporter]

Can you check if locked by explore or tgitcache.exe?

Original comment by lzn...@gmail.com on 20 Mar 2011 at 12:27

[GoogleCodeExporter]

According to ProcessExplorer it was opened by both, but killing tgitcache.exe 
resolved problem.

Original comment by mwisnicki@gmail.com on 20 Mar 2011 at 2:30

[GoogleCodeExporter]

which file locked?

Original comment by lzn...@gmail.com on 20 Mar 2011 at 3:48

[GoogleCodeExporter]

Unfortunately I didn't note it :(

Original comment by mwisnicki@gmail.com on 20 Mar 2011 at 10:59

[GoogleCodeExporter]

OK, it happened once again after I cloned 
https://github.com/philikon/SyncBling.git and did some edits, now I can't 
rename toplevel directory.

According to procexp the handle opened by tgitcache is to the toplevel 
directory (D:\devel\projects\firefox-4-wip\SyncBling). Closing the handle 
allows renaming of the folder.

Sadly, repeating exactly what I did:
1. clone
2. enter directory
3. edit package.json
4. go up
5. rename folder

didn't reproduce the error.

Original comment by mwisnicki@gmail.com on 23 Mar 2011 at 4:52

[GoogleCodeExporter]

1.6.5.0 x86, bug is still alive.
Cannot move/rename reporitory, "gc" operation fails at the end with access 
denied etc.
Icons overlays are on. Killing "TGitCache" helps if you perform your operation 
fast enough before buggy cacher restarts.
Steps are already provided by previous reporters. What additional information 
can help to fix this bug?

The most simple way to reproduce I ever seen is to init new repo, wait until 
repo's folder receive overlay icon and try to delete whole repo.

Original comment by hFFFFF...@gmail.com on 15 May 2011 at 10:05