Git gc does not remove garbage files

[mateuszkuta256]

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

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.46.2. windows.1
cpu: x86_64
built from commit: 1e20af0e809e08cca5714727dfa0fb50c0c4664d
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon libcurl: 8.10.1
OpenSSL: OpenSSL 3.2.3 3 Sep 2024
zlib: 1.3.1

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 10.0.19045.48941

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

cmd

• What commands did you run to trigger this issue?

  • $ git gc

  • if there's another git process running, it may ask:

    Unlink of file '...' failed. Should I try again? (y/n)

    select n

  • $ git count-objects -v will display:

    warning: no corresponding .idx: .git/objects/pack/pack-[...].pack
    [...]
    garbage: 1
    size-garbage: 1857
    

  This is expected, but if you terminate the other git process and run gc again, it won't remove .pack that corresponds to the missing index. The only way to get rid of it is to recreate the index (index-pack) before the next gc

• What did you expect to occur after running these commands?

  • gc will remove garbage .pack even if the corresponding index is missing
    OR
  • git will never remove .idx if the corresponding .pack is locked

• What actually happened instead?
  .idx was removed and orphaned .pack, which will be ignored in subsequent gc

[dscho]

• gc will remove garbage .pack even if the corresponding index is missing
  or

Hmm. That might be possible. But. The idea is that packfiles are indexed while they are downloaded, and as long as there is no .idx file they are not considered to be active. You may very well delete (on platforms where files can be deleted while they are being written to) an in-progress packfile.

• git will never remove .idx if the corresponding .pack is locked

This might be the easier variant: You would need to replace this call:

	string_list_sort(&names);

by a call to qsort() using a compare function that would sort .idx files after their corresponding .pack files.