git on windows 10 cloning over VPN using drive letters fails

[paulkinz]

• [ ] 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.37.1.windows.1

$ git --version --build-options

git version 2.37.1.windows.1
cpu: x86_64
built from commit: 323a69709944b193bb5cee81ff09fe9a4a686df5
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

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

Windows 10

$ cmd.exe /c ver

 [Version 10.0.19043.1826]

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

Defaults

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related to the issue you're seeing?

Using ui.com to create a VPN, and RDP to map drives back and forth between two W10 systems.

Details

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

Vanilla CMD shell

• What commands did you run to trigger this issue? If you can provide a Minimal, Complete, and Verifiable example this will help us understand the issue.

git clone S:\cap2office c:\cap2office
between two W10 systems over the above VPN setup

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

I expected my remote repository on S: to be cloned onto the local C:\cap2office

• What actually happened instead?

I got an error, said repository was NULL

• If the problem was occurring with a specific repository, can you provide the URL to that repository to help us with testing?

None

BIG shoutout to Jeff Hostetler, I fought with this problem for several days, no useful advice from stackoverflow, then I posted to the git list and Jeff speculated that the problem might be that git doesn't understand that S: is a remote disk and so is trying to do hardlinks and is of course failing, but apparently doesn't know that it failed given the bogus error message. Jeff suggested adding --no-hardlinks to the clone command and that fixed the problem!

[rimrul]

The discussion on the mailing list is here: https://lore.kernel.org/git/7391734b-c5d7-1f8c-912b-a75833a3070a@kinzelman.com/T/#t

[dscho]

So if I interpret https://lore.kernel.org/git/d4a77fd1-6be7-6466-8c94-6e2552184094@kinzelman.com/ correctly, it means that git clone tries to create hard-links, and that operation pretends to succeed, but it actually does not.

Before we can try to address this, we will need a more reproducible MCVE.

[paulkinz]

I'm new here so I'm hoping that just posting my response is the appropriate thing. I'll post after your text because it's so short, I don't know whether you want history to be up or down.

On 7/25/2022 4:18 AM, Johannes Schindelin wrote:

So if I interpret @.***/ correctly, it means that |git clone| tries to create hard-links, and that operation pretends to succeed, but it actually does not.

Before we can try to address this, we will need a more reproducible MCVE https://stackoverflow.com/help/mcve

This bug is not amenable to producing a file and saying 'try this', it's unfortunately a whole environment. I'll describe two scenarios, the first being easier to reproduce but may not provoke the bug because it's not the same as my environment. But if you can provoke the bug, it'd be easier to debug so probably worth trying first. The second is reflective of my environment.  And I'm barely a novice, so I'll apologize in advance if I get some commands wrong. :-)

1) local network environment

Have two Windows 10 systems networked together. On Sys0 create a git central repository (git init c:\testgit) Commit a couple of files in that repository. On Sys1, map \Sys0\c: to Sys1 drive S:\ On Sys1 clone that repository (git clone s:\testgit c:\testgit) See if those repository files are available on Sys1. If so, then this environment is working and does not provoke the bug

2) VPN environment

Note: I didn't actually do the install of ui.com and RDP so I'm a bit hazy about exactly how to do this.

Have two Windows 10 systems on two different LANs connected to the internet. Create an account on ui.com - it's free for small uses like this. Install the ui.com app which includes VPN on the two systems. On Sys1, turn on VPN into Sys0.

Install Microsoft RDP on the two systems. On Sys1, RDP into Sys0 so that the Sys1 monitor displays a Sys0 desktop. On Sys0 create a git central repository (git init c:\testgit) Commit a couple of files in that repository. On Sys1, map \Sys0\c: to Sys1 drive S:\ On Sys1 clone that repository (git clone s:\testgit c:\testgit) See if those files are available on Sys1. If so, then this environment is working and has not provoked the bug If the files are not there, then try: Delete the c:\testgit file tree On Sys1 clone that repository (git clone --no-hardlink s:\testgit c:\testgit) You should see a valid repository on Sys1 as a result of no-hardlink

[rimrul]

On Sys1, map \Sys0\c: to Sys1 drive S:\

The details here might be important. Do you map \\tsclient\c\ or do you share the drive and map it via \\hostname\c$\? And how do you map it to a drive letter? SUBST, NET USE, group policy, GUI?

[paulkinz]

Good questions.

In my flailing around trying to understand git, I probably tried both ways, both via tsclient and hostname and my impression was that they both fail the same way. I think I tried cloning both ways and getting failures until somebody suggested the no-hardlinks switch. The most recent way was on Sys1 where I typed in the search bar: \10.1.10.71 and up pops a Windows Explorer window and I do a right-click and "map to drive" and select S.

I believe I tried it in the other direction as well so on Sys0: Windows Explorer | right click on the \tsclient\c  item, then map to drive.

And once mapped I change the file protection to everybody all access.

I also had problems with usernames so I did  System env variable    GIT_TEST_DEBUG_UNSAFE_DIRECTORIES=true and     git config --global --add safe.directory %(prefix)///tsclient/C/cap2office

I did those things on both systems not being clear whether they were both necessary on both systems or not.

On 7/25/2022 2:34 PM, Matthias Aßhauer wrote:

On Sys1, map \Sys0\c: to Sys1 drive S:\

The details here might be important. Do you map |\tsclient\c| or do you share the drive and map it via |\hostname\c$|? And how do you map it to a drive letter? |SUBST|, |NET USE|, group policy, GUI?

[jeffhostetler]

Adding a note here so that I get tracking email.

[dscho]

@jeffhostetler for the record, there is also this button on the upper right-hand side:

[jeffhostetler]

d'oh. i looked for it and didn't see it. guess it got lost in all the visual noise in the right column. :-)