Possible git bug when working with Microsoft Mapped drives

Possible git bug when working with Microsoft Mapped drives

[Paul Kinzelman]

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

Re: Possible git bug when working with Microsoft Mapped drives

[Jeff Hostetler]

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

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.

Again, this is just a guess.

There are also some GIT_TRACE* environment variables that might
be helpful if the above doesn't help.

Jeff

https://git-scm.com/docs/git-clone

Re: Possible git bug when working with Microsoft Mapped drives

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]

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).
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Possible git bug when working with Microsoft Mapped drives

[Paul Kinzelman]

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

Re: Possible git bug when working with Microsoft Mapped drives

[Jeff Hostetler]

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

Re: Possible git bug when working with Microsoft Mapped drives

[Paul Kinzelman]

I'm trying, but their 2FA won't work for me. I'm not getting their
email (yes I checked junk and spam) and there doesn't seem to
be a PC based alternative. I don't want to install another phone app.

On 7/19/2022 3:02 PM, Jeff Hostetler wrote:
> 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).
>>