Regression in Git for Windows 2.54: fetch-triggered auto maintenance fails to unlink .git/objects/pack/*.idx with geometric maintenance

[PatrykMis]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.54.0.windows.1
cpu: x86_64
built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.19.0
OpenSSL: OpenSSL 3.5.6 7 Apr 2026
zlib: 1.3.2
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 10

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.19045.7184]

Options set during installation

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

This seems to be a regression in Git for Windows 2.54.0.windows.1.

The issue appears to be isolated to fetch-triggered auto-maintenance when the geometric maintenance strategy is enabled.

The repository itself appears healthy:

git fsck --full

succeeds.

Also:

git gc --prune=now --aggressive

succeeds.

The failure does not seem to be caused by general repository corruption or by a normal git gc failure.

The following individual maintenance tasks also complete successfully when run manually:

git maintenance run --task=incremental-repack
git maintenance run --task=commit-graph
git maintenance run --task=pack-refs
git maintenance run --task=loose-objects
git maintenance run --task=gc

This suggests that the failure is probably not in one individual maintenance task by itself, but rather in the full auto-maintenance sequence / orchestration after git fetch.

The workaround is:

git config --global maintenance.strategy gc

Alternatively:

git fetch --no-auto-maintenance

also avoids the failure.

Terminal/shell

bash, cmd, powershell

Commands that trigger the issue

git fetch
git fetch --all
git fetch --all -p --tags -f

Expected behaviour

git fetch should complete successfully.

It should not fail while trying to unlink .idx files from .git/objects/pack/ during cleanup or auto-maintenance.

Actual behaviour

After upgrading to Git for Windows 2.54.0.windows.1 / 2.54.0-1, git fetch intermittently fails with:

Unlink of file '.git/objects/pack/pack-<hash>.idx' failed. Should I try again?

The failing files are always under:

.git/objects/pack/*.idx

This happens only in some repositories and only with Git for Windows 2.54.

The problem is independent of the shell: it reproduces in Git Bash, CMD and PowerShell.

Running as Administrator does not change the behavior.

I also checked for external file handles and did not find any external process keeping the affected files open. The files can be copied, moved and deleted normally from Explorer outside of the failing Git operation.

Important isolation details:

git fetch --no-auto-maintenance

succeeds.

Also, when geometric maintenance is avoided, the same fetch operation succeeds, for example:

git -c maintenance.strategy=gc fetch

or after configuring:

git config --global maintenance.strategy gc

the problem no longer reproduces.

This strongly suggests that the issue is in the fetch-triggered auto-maintenance path, specifically when the geometric maintenance strategy is involved.

Possible cause:

This looks like a Windows-specific handle/lifecycle issue in the fetch-triggered auto-maintenance sequence. One part of the maintenance sequence may still have an open handle to a pack index file while a later cleanup step tries to unlink the same .idx file.

Why this looks like a regression:

• The problem started after upgrading to Git for Windows 2.54.
• It does not reproduce when geometric maintenance is disabled.
• It does not reproduce with git fetch --no-auto-maintenance.
• The repository passes git fsck --full.
• Manual aggressive GC succeeds.
• Individual maintenance tasks succeed.
• The failure is limited to .git/objects/pack/*.idx cleanup during fetch-triggered maintenance.

Repository

Normal local working tree, non-bare repository.

The affected repositories are private, but I can provide additional diagnostic output if needed, such as:

git config --show-origin --get-regexp "^(maintenance|gc|fetch|core\.fsmonitor|feature)\."
git count-objects -vH

[PatrykMis]

Additional diagnostic output from one affected repository:

output of: git count-objects -vH

count: 2395
size: 5.13 MiB
in-pack: 10914
packs: 21
size-pack: 4.64 MiB
prune-packable: 122
garbage: 0
size-garbage: 0 bytes

One detail that may be relevant: this repository has 21 pack files, so it plausibly crosses the auto-maintenance / repack heuristics in 2.54. The repository still reports garbage: 0, and both fsck and aggressive GC succeed.

Clarification: the git count-objects -vH output above was captured before running the failing git fetch, not after the failure.

So the repository already had 21 pack files before fetch-triggered auto-maintenance ran. The repository still reports garbage: 0, and both git fsck --full and git gc --prune=now --aggressive succeed.

[dscho]

The root cause is likely a missing child.odb_to_close in maintenance_task_geometric_repack(). Here's the chain:

1. maintenance_task_geometric_repack() calls pack_geometry_init()
2. The sort comparator pack_geometry_weight() calls open_pack_index(p), which calls check_packed_git_idx() which in turn mmap()s every .idx file via xmmap()
3. It then spawns git repack -d --geometric=N as a child process, but does NOT set child.odb_to_close.
4. The child git repack creates the new pack and tries to delete old .idx files via unlink_pack_path() -> unlink() -> mingw_unlink(path, 1)
5. On Windows, MapViewOfFile keeps a handle open on the file. The parent's mmap()s prevent deletion -> "Unlink of file failed."

The gc strategy never hits this.

The GC background task sets child.odb_to_close = the_repository->objects;. So does the GC's internal repack call. When run_command() sees this, it calls odb_close() which calls close_pack() -> close_pack_index() -> munmap() on every .idx file before the child is spawned. The child never encounters locked files.

Every other maintenance sub-task also gets this right:

• multi_pack_index_expire() sets odb_to_close ✓
• multi_pack_index_repack() sets odb_to_close ✓
• maintenance_task_gc_background() sets odb_to_close ✓
• GC's internal repack at gc.c:1019: sets odb_to_close ✓
• maintenance_task_geometric_repack() does not set this flag ✗

I think that the fix is as easy as adding child.odb_to_close = the_repository->objects; after child.git_cmd = 1; here. This will unmap all .idx files before spawning git repack, exactly as all the other tasks do.

This seems to be a regression uncovered by Git v2.54 (not just Git for Windows): 452b12c ("builtin/maintenance: use 'geometric' strategy by default") made geometric the default strategy. Before that, git fetch auto-maintenance used GC, which never had this problem.

Of course the real bug was introduced by 9bc1518 ("builtin/maintenance: introduce 'geometric-repack' task"), it just did not matter as much because geometric repacking was not made the default until now.

[PatrykMis]

Thanks, that explanation matches all observations on my side.

In the affected repositories:

• git fetch --no-auto-maintenance succeeds
• git -c maintenance.strategy=gc fetch succeeds
• git gc --prune=now --aggressive succeeds
• individual maintenance tasks succeed
• the failure only happens with fetch-triggered auto-maintenance using the geometric strategy

So the missing child.odb_to_close = the_repository->objects; in maintenance_task_geometric_repack() sounds like a very plausible root cause.

Since this seems to be an upstream Git bug exposed by Git v2.54 making geometric maintenance the default, would you prefer to send the fix upstream yourself, or should I report this to the Git mailing list?

I’m happy to test a patched Git for Windows build and provide a Tested-by if useful.