Possible git bug when working with Microsoft Mapped drives

> 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.
> 
> Any suggestions would be appreciated. Thanks!
> -Paul Kinzelman, Peralta NM
> 

> 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.

> 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).

> Thank you! Jeff was right on, but I didn't want to create extra noise
> on the elist, so I replied just to him.
> 
> His suggestion of the --no-hardlinks
> caused it to work!
> 
> Might be good to test to see if a drive letter is on a remote system
> and do that automagically.
> 
> On 7/18/2022 3:38 PM, brian m. carlson wrote:
>> 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).
> 

> Could you maybe create an issue against GFW for this so that we don't
> forget about it?
>
> https://github.com/git-for-windows/git/issues
>
> Jeff
>
>
> On 7/18/22 5:55 PM, Paul Kinzelman wrote:
>> Thank you! Jeff was right on, but I didn't want to create extra noise
>> on the elist, so I replied just to him.
>>
>> His suggestion of the --no-hardlinks
>> caused it to work!
>>
>> Might be good to test to see if a drive letter is on a remote system
>> and do that automagically.
>>
>> On 7/18/2022 3:38 PM, brian m. carlson wrote:
>>> 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).
>>