Git for Windows unable to fetch/pull/clone valid repository

[LordKiRon]

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

Happens both on 2.52 (latest windows 1) and earlier versions down to 2.43 including tested,  all x64, so specific version is not relevant.

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.26200.7623]
(c) Microsoft Corporation. All rights reserved.

Options set during installation

Defaults, but tried other variants too

Other interesting things

No response

Terminal/shell

tried all 3 options (cmd, powerShell/Git-Bash , mainly use cmd

Commands that trigger the issue

fetch , pull , clone ...

Expected behaviour

To get the repository to the disk

Actual behaviour

Getting :
fatal: pack has bad object at offset 237543629: inflate returned -5
fatal: fetch-pack: invalid index-pack output

Repository

Happens with specific repository , but can't share, it contain private data and its 67GB in size.

The problem happens with any transport (https, ssh, git) as well as when "unpacking" bandle.

However , this is not repository problem as same operations can be performed on Linux (testd Debian 13, Ubuntu 24, Mint 22.3) no problem.
Also tried to check and "fix" it on server (Synology DS1522+ NAS running built-in Git Server) and also no erros detected and can open (clone/fetch/pull) locally no problem. Even imported it in Gitea (docker) over network no problem.

The repository contains among other things, multiple versions of same text file (SQL database dump) of about 2G+ , versions added on weekly basis for about a year now, and until recently there we no problems. But started.

Tried to repack on server using different compression (changed to 9) depth and window , but the only thing that changes when fetching on Windows as result of the compression is offset it fails. But without it it fails on exactly same offset each time.

As being a programmer myself tried to debug things a bit, and it all comes to "index_pack_lockfile()" function in pack_write.c file , that at some point return NULL. Last one in function , where
if (is_well_formed) *is_well_formed = 0; return NULL;
So, I guess "if (read_in_full(ip_out, packname, len) == len && packname[len-1] == '\n')" returned false as last character was not a new line ('\n' == 10 , while we had packname[len-1] == 0).
Also at this point "*is_well_formed=6283216" (so it sets it to 0) , "len=46" , the "packname" = AgAAAAAAAAABAAAAAAAAAHDeXwAAAAAAAAEHyh8FAABgqpGg938AAAAAAAAAAAAAAAAAAAAAAACg3l8AAAAAAAAAAAAAAAA= (in base 64, sorry did not had any reasonable means to export array)

Again, no issues with same repository on Linux

And its surely not a memory problem as have plenty both on Windows and Synology NAS .

Seems to me the issue accured somewhere earlier , when decoding the pack, but since I am have no clue in Git code and algorithms, can't drill too much into it myself.
If needed can assist in hunting down this one by running some code with debug logging and such.

[dscho]

This is probably highly related to #2179.

[LordKiRon]

This is probably highly related to #2179.

Wow ! 7 years old issue , rather significant and still not resolved ?
But it does looks like good chance that this (Windows long is 32 bit) is the reason.
max long in 32 bit is 2,147,483,647 (~2.1GB) , which is probably in range of my file size.

I tried to debug a bit and it seems that the problem is due "read_in_full" function returning 0 (NULL) instead of "len" as expected in proper use case and this can only happen if
' ssize_t loaded = xread(fd, p, count);
if (loaded < 0)
{
return -1;
}
if (loaded == 0)
{
return total;
}
'
returns 0 (as loaded == 0) on first iteration , when total still == 0.

However , ssize_t is defined as __int64 , so this is not root point of failure , it probably somewhere way earlier in "xread" code

[LordKiRon]

"Confirmed" :
xread(8,0x5fde20,46) returns 0 , while count == 0 and buf = 0x5fde20 , meaning on first read. Resulting returning total , which is at that point is 0. While if (nr < 0) inside xread() never happens , so its clearly nr = read(fd, buf, len); returned 0.
Since, unless I am mistaken, read() is a system (POSIX) function call it means the problem is with stream (socket , pipe or whatever we have there) , meaning it was probably closed too early, without fitting all data.
Since this works ok on Linux one can assume that the server side is ok , and since it happens on any transport including bundle I would guess we can rule out SSH and such quirks.

So, I guess at this point I have to give up on my side as I really have no idea how this stream/socket being written locally and by whom, decompression maybe ?

Updated: so bottom line I was digging in wrong direction, basically confirmed that issue is not in git main process code that just reads the output of child processes , but in " index-pack" .