From: Jeff Hostetler Date: Tue, 19 Jul 2022 21:02:10 GMT Subject: Re: Possible git bug when working with Microsoft Mapped drives Message-ID: In-Reply-To: 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). >