Re: Possible git bug when working with Microsoft Mapped drives

> On 2022-07-18 at 20:46:44, Jeff Hostetler wrote:
>> On 7/18/22 4:28 PM, Paul Kinzelman wrote:
>>> I'm using git version 2.37.1.windows.1 and Windows 10
>>>
>>> I've got two systems which are miles apart and so are not on the same
>>> LAN, and I have connected them together using the ui.com VPN and M$
>>> RDP/TSclient. I mapped each system's C: drive to be accessed by the
>>> other system as Drive X: and I can transfer files back and forth
>>> initiated on each system.
>>>
>>> I can also see all the repository files on the source system, including
>>> the tree of files under the .git directory. Note I had to unhide the
>>> .git folder so that I could see that folder from the other system.
>>>
>>> However, when I run 'git clone' on one system to get the repository from
>>> the other system, git seems to think the repository on the other
>>> system is empty when it's not. As I said, I can even do a directory
>>> and see all the other files.
>> I can't duplicate your setup, so I'll just speculate out loud
>> here.  I have to wonder if the "X:" drive letters are tricking
>> Git to thinking that the remote instance is actually local and
>> Git is trying to use some shortcuts. (For example, it might
>> hardlink them rather than copy them on Linux.)
>>
>> So I'm wondering if "--no-local" or "--no-hardlinks" or using
>> a file URL rather than a pathname might make it behave differently.
> It may also be the case that the remote file system lacks some
> functionality that Git needs.  For example, Windows can support mapping
> HTTP DAV resources as drives, but the DAV protocol is incapable of
> providing certain operations that Git expects of a file system (Git
> roughly needs something that's POSIX compliant, but can paper over case
> insensitivity) and thus such a disk simply can't work with Git.
>
> This may end up looking like the file system is empty because, for
> example, the function to query directory contents may return an error.
> The contents may not actually be empty, but because they cannot be
> enumerated in the way Git needs them to be, it appears that way.
>
> Again, I don't know if this is the case here, but you're the second
> person recently to have seen problems with using RDP for this purpose.
> You may wish to try SFTP, which should work (at least it does for Unix
> systems), or possibly SMB/CIFS (which may or may not work, but I believe
> it typically does).