Git unlink failure (on Windows)

[Bruce]

I'm hitting an occaional problem when I do a git fetch (on Windows :-() on Chromium. It's happened twice now. The unlink step fails (for dozens of files) and I have to type n/enter multiple times to get past it. It happened yesterday and then again today. I can see that a copy of gc.exe has a handle to the file, but I don't know why.

Just thought I'd ask to see if anybody else has been seeing this problem. Here's what it looks like:

Auto packing the repository for optimum performance. You may also

run "git gc" manually. See "git help gc" for more information.

Counting objects: 3747412, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (750719/750719), done.

Writing objects: 100% (3747412/3747412), done.

Total 3747412 (delta 3004380), reused 3582685 (delta 2873901)

Unlink of file '.git/objects/pack/pack-17d4847e3907a8c7c6a17c440a2b8bbe7a19f9d6.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-1895e39c0d4dd77e38f5ef0eba9440c4c1b225fe.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-1a46e1ee67ee85a6ed8a9db83045c6e89a7677a3.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-1a7fd21a7d80ccf0dbaf49f394479c6769f7e9cd.pack' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-1a7fd21a7d80ccf0dbaf49f394479c6769f7e9cd.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-1f35f2238be59021eebe8d330e5d05479ce988ae.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-2087a3a8051e42fb482b5eeb63e7d5b31c8e4eb1.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-24d144fc6ce966d3e1c2cfee1cc3dabb91199d65.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-2a2e9434e9467faf140ee1e1578e531989391e70.idx' failed. Should I try again? (y/n) n

Unlink of file '.git/objects/pack/pack-31fd6608ba1a611d48564a4f8c32a2e2efadc37e.idx' failed. Should I try again? (y/n) n

...

[Michael Moss]

There have been a couple reports of similar issues over the years, but no clear cause. See also crbug.com/345301 and crbug.com/350413. Does running gc manually work? Or setting "pack.threads 1" as mentioned in the bug?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Peter Kasting]

Happens to me every several months.  I hit 'n' a bunch.  :(

PK

[Michael Moss]

Happens once, then stops again for a few months, or happens repeatedly, then at some point mysteriously stops (maybe after a reboot, as senorblanco mentions in the bug)?

On Wed, Jun 3, 2015 at 1:21 PM, Peter Kasting <pkas...@chromium.org> wrote:

Happens to me every several months.  I hit 'n' a bunch.  :(

PK

--

[Peter Kasting]

On Wed, Jun 3, 2015 at 1:27 PM, Michael Moss <mm...@chromium.org> wrote:

Happens once, then stops again for a few months, or happens repeatedly, then at some point mysteriously stops (maybe after a reboot, as senorblanco mentions in the bug)?

Always happens exactly once at a time.

PK 

[John Abd-El-Malek]

same for me

--

[Dale Curtis]

Are you keeping your sources in a folder excluded by bit9/av? I.e. x:\src by default. 

- dale

[Bruce Dawson]

Yep. All source is in d:\src.

[John Abd-El-Malek]

Yes

On Wed, Jun 3, 2015 at 1:59 PM, Dale Curtis <dalec...@chromium.org> wrote:

[Greg Thompson]

I diagnosed this in http://crbug.com/350413. The cause is clear: git proc A holds a bunch of files open while it launches git proc B for a gc, which tries to delete them. Maybe this works on *nix, but it doesn't on Windows.

[Michael Moss]

I know the random timing of this makes it hard to debug, but were you ever able to try the "git config --local pack.threads 1" suggestion from the other bug to see if that helps? Alternatively, if this only ever happens with the automatic gc, and never when manually running 'git gc', you could turn off auto gc for that repository with "git config --local gc.auto 0" (or for all repositories with "git config --global gc.auto 0"). Of course, then you should remember to manually gc periodically, to keep things tidy and efficient.