Checkout of partial clone results in 'error: unable to read sha1 file of ...' (but works on linux)

[nharrer]

• 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 --build-options

git version 2.26.1.windows.1
cpu: x86_64
built from commit: 14af9f9d205f4a6a033c7b6f48980d1eeee2c610
sizeof-long: 4
sizeof-size_t: 8

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

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18363.778]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

Details

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

MinTTY Bash

• What commands did you run to trigger this issue?

Here is a complete example which you can run in git bash:

# create repo1
mkdir repo1
cd repo1
git init
# enable partial clone on server
git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1
mkdir dir1
mkdir dir2
echo test > dir1/file1
echo test > dir2/file2
git add *
git commit -m "some files"
cd ..

# create partial clone
git clone --depth 1 --filter=combine:blob:none+tree:0 --no-checkout "file://$(pwd)/repo1" repo2
cd repo2/
# this fails
git checkout master -- dir2/

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

No errors

• What actually happened instead?

The last command (git checkout master -- dir2/) fails with:

remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), 190 bytes | 190.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 46 bytes | 46.00 KiB/s, done.
error: unable to read sha1 file of dir2/file2 (9daeafb9864cf43055ae93beb0afd6c7d144bfa4)

Note: The same example works in linux with git version 2.25.1

[dscho]

Performance Tweaks FSCache: Enabled

I can reproduce this, but only with FSCache enabled, i.e. with core.fscache=true. If I turn it off, your reproducer works just like on Linux.

So this is a workaround you can use until we figure this out what is going wrong with enabled FSCache.

[dscho]

So this is a workaround you can use until we figure this out what is going wrong with enabled FSCache.

A preliminary diagnosis: when an promised object is missing, we fetch it via promisor_remote_get_direct() in

git/sha1-file.c

Line 1516 in 14af9f9

promisor_remote_get_direct(r, real, 1);

. During that function call, somewhere deeper in the call chain, we then call reprepare_packaged_git() in

git/fetch-pack.c

Line 1778 in 14af9f9

reprepare_packed_git(the_repository);

. In this call, we eventually call opendir() to enumerate all new pack files:

git/packfile.c

Line 810 in 14af9f9

dir = opendir(path.buf);

When FSCache is turned on, this opendir() accesses a cached copy of the directory, which is now stale. The solution will be to invalidate it.

[nharrer]

I can reproduce this, but only with FSCache enabled, i.e. with core.fscache=true. If I turn it off, your reproducer works just like on Linux.

So this is a workaround you can use until we figure this out what is going wrong with enabled FSCache.

Yes, I had core.fscache turned on. And it works when I turn it off. Thank you!!

[dscho]

Closing as stale.