当目标是网络驱动器时，git clone 失败

Question

I'm having issues cloning a git repository on Windows using git in a MINGW32 shell. The basic symptom is that cloning this specific repository works fine when the destination is on my local disk but the identical command fails when the clone destination is on a network drive. Here is the local clone command (with the repo name redacted):

drichards@LT-DR MINGW32 /c/temp
$ git clone -v --progress <repo> gitrepo
Cloning into 'gitrepo'...
POST git-upload-pack (250 bytes)
remote: Counting objects: 82, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 82 (delta 26), reused 0 (delta 0)
Unpacking objects: 100% (82/82), done.
Checking connectivity... done.

Trying exactly the same procedure on a network drive results in failure. In this case drive S: is mapped to a network location.

drichards@LT-DR MINGW32 /s/temp
$ git clone -v --progress <repo> gitrepo
Cloning into 'gitrepo'...
POST git-upload-pack (250 bytes)
remote: Counting objects: 82, done.
remote: Compressing objects: 100% (71/71), done.
fatal: failed to read object 9b081a422a5f7d06ff5a2cb4889d26b4f18c6181: Permission denied
fatal: unpack-objects failed

The folder 'gitrepo' is temporarily created and then cleaned up on failure, so I can't easily pick through it to find out what went wrong. It seemed like a fairly straightforward permissions issue, so I thought attaching ProcMon would be a good solution to finding out where it had gone wrong, however, when ProcMon is running, the clone works with no problems.

This seems to imply that there is some kind of consistency problem or race condition which is occurring when the destination is a network drive. I have collected the output when the destination is the network drive with GIT_TRACE set to 1 and ProcMon not connected - that doesn't reveal anything interesting to my eyes. Here is the failure moment:

11:07:48.262535 run-command.c:336       trace: run_command: 'unpack-objects' '--pack_header=2,82'
11:07:48.324578 git.c:350               trace: built-in: git 'unpack-objects' '--pack_header=2,82'
fatal: failed to read object 9b081a422a5f7d06ff5a2cb4889d26b4f18c6181: Permission denied
fatal: unpack-objects failed

I have also tried asking git to validate objects by adding git clone -c transfer.fsckObjects=1 but that doesn't change the symptoms.

As alluded to earlier, the problem seems specific to a repository. Here are a few other data points:

• The code hosting server (which is separate from all the other machines mentioned so far) has many repositories and I've cloned several others onto the network with no issue.
• The issue occurs regardless of whether a regular or bare clone is made
• There doesn't appear to be anything special about the object which causes the failure (the packed size is intermediate - 727 bytes)
• If I attach ProcMon and disconnect whilst git is unpacking, the process still fails, usually on a different object.
• A colleague also experiences the same success / fail patterns depending on the destination location.
• The process still fails if I execute git from a local directory, specifying the target directory as a UNC path

Here are a few vital stats on my local machine:

$ systeminfo
<snip>
OS Name:                   Microsoft Windows 8.1 Pro
OS Version:                6.3.9600 N/A Build 9600
<snip>
$ uname -a
MINGW32_NT-6.3-WOW LT-DR 2.5.0(0.295/5/3) 2016-03-31 18:26 i686 Msys
$ git --version
git version 2.8.3.windows.1

The server hosting the target directories in question runs Windows Server 2008. The code server is running gitlab-ce 8.9.3.

Answer 1

This is where the notion of " promissor remote " comes in.

That notion is used with the transfer.fsckobjects configuration: it tells " git fetch " to validate the data and connected-ness of objects in the received pack; the code to perform this check has been taught about the narrow clone's convention that missing objects that are reachable from objects in a pack that came from a promissor remote is OK.

Before Git 2.29 (Q4 2020), while packing many objects in a repository with a promissor remote, lazily fetching missing objects from the promissor remote one by one may be inefficient.

The code now attempts to fetch all the missing objects in batch (obviously this won't work for a lazy clone that lazily fetches tree objects as you cannot even enumerate what blobs are missing until you learn which trees are missing).

That might help with your git clone from a network drive.

See commit e00549a , commit 8d5cf95 (20 Jul 2020) by Jonathan Tan ( jhowtan ) .
^{(Merged by Junio C Hamano -- gitster -- in commit 5c454b3 , 04 Aug 2020)}

pack-objects : prefetch objects to be packed

^{Signed-off-by: Jonathan Tan}

When an object to be packed is noticed to be missing, prefetch all to-be-packed objects in one batch.

---

And still with Git 2.29 (Q4 2020), " git fetch " ^{( man )} works better when the packfile URI capability is in use.

See commit 0bd96be , commit ece9aea , commit 42d418d (17 Aug 2020) by Jonathan Tan ( jhowtan ) .
^{(Merged by Junio C Hamano -- gitster -- in commit bdccf5e , 03 Sep 2020)}

fetch-pack : make packfile URIs work with transfer.fsckobjects

^{Signed-off-by: Jonathan Tan}

When fetching with packfile URIs and transfer.fsckobjects=1 , use the --fsck-objects instead of the --strict flag when invoking index-pack so that links are not checked, only objects.

This is because incomplete links are expected. (A subsequent connectivity check will be done when all the packs have been downloaded regardless of whether transfer.fsckobjects is set.)

This is similar to 98a2ea46c2 (" fetch-pack : do not check links for partial fetch", 2018-03-15, Git v2.17.0-rc1 -- merge ), but for packfile URIs instead of partial clones.

---

With Git 2.31 (Q1 2021), we know more about the packfiles downloaded with the packfile URI feature.

See commit bfc2a36 (20 Jan 2021) by Jonathan Tan ( jhowtan ) .
^{(Merged by Junio C Hamano -- gitster -- in commit d03553e , 03 Feb 2021)}

Doc : clarify contents of packfile sent as URI

^{Signed-off-by: Jonathan Tan}

Clarify that, when the packfile-uri feature is used, the client should not assume that the extra packfiles downloaded would only contain a single blob, but support packfiles containing multiple objects of all types.

technical/packfile-uri now includes in its man page :

blobs are excluded, replaced with URIs. As noted in "Future work" below, the server can evolve in the future to support excluding other objects (or other implementations of servers could be made that support excluding other objects) without needing a protocol change, so clients should not expect that packfiles downloaded in this way only contain single blobs.

---

With Git 2.33 (Q3 2021), the description of uploadpack.blobPackfileUri of a packfile-uri (used for fetching, including with a network drive path as in the OP) is enhanced:

See commit 3127ff9 (13 May 2021) by Teng Long ( dyrone ) .
^{(Merged by Junio C Hamano -- gitster -- in commit 8e1d2fc , 10 Jun 2021)}

packfile-uri.txt : fix blobPackfileUri description

^{Signed-off-by: Teng Long
Reviewed-by: Jonathan Tan}

Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt and the correct format also can be seen in t5702.

technical/packfile-uri now includes in its man page :

server to be configured by one or more uploadpack.blobPackfileUri= <object-hash> <pack-hash> <uri> entries.

Whenever the list of objects to be sent is assembled, all such blobs are excluded, replaced with URIs.

As noted in "Future work" below, the server can evolve in the future to support excluding other objects (or other implementations of servers could be made that support excluding other objects) without needing a protocol change, so clients should not expect that packfiles downloaded in this way only contain single blobs.