misterious GIT failure

[matthew patton]

Adam Dinwoodie wrote:> This looks like some sort of problem writing to disk to me.  Where are> you storing your Git repositories?  Is it on a regular NTFS disk
plain NTFS (win10 exterprise) with hundreds of GB free. I blew away contents of /tmp just to make sure it wasn't something silly going on there. It's git pack/unpack aborting the read/write from the pipe which causes SSH to then close and tear down the connection. SSH client helpfully provides stats on how many packets transferred up/down.
Achim Gratz wrote:> That seems to indicate some sort of behavioral based firewalling or IDS
I thought it could be that too. Tried with and without corporate VPN. But it's worked for over a year with this config and nary a hiccup. And anyway if I immediately switch to my WSL (Ubuntu) window or Git-Bash and issue the Git commands they run perfectly. Yes my Cygwin and WSL and Git-Bash share the exact same repository directories.
If I blow away the entire Cygwin installation (c:\cygwin64) and re-install Cygwin Git it will resume working and do so for a while. Like I mentioned previously re-installing Git does not solve the issue. And yes my SSH sessions while Git is "broken" continue to work like a champ, so it's not SSH.
I've attached cygcheck. Before I even posted I went looking for strace() to no avail. I also even did a manual connection attempt like this:    ssh blah | git index-pack --stdin -v --fix-thin '--keep=fetch-pack 1011 on SOHO-GP4D633' --pack_header=2,1635
and it would fail in the same manner as when it had been invoked "normally".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out
Type: application/octet-stream
Size: 126781 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20210108/51a029b5/attachment-0001.obj>