{"thread":{"id":"58182","subject":"Possible git bug when working with Microsoft Mapped drives","startedAt":"2022-07-18T20:29:24Z","lastAt":"2022-07-19T23:58:57Z","messageCount":6,"participants":["Paul Kinzelman","Jeff Hostetler","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"459327","messageId":"f946c577-d3d6-212c-cec5-a6c63856b77d@kinzelman.com","threadId":"58182","inReplyTo":null,"subject":"Possible git bug when working with Microsoft Mapped drives","fromName":"Paul Kinzelman","fromEmail":"paul@kinzelman.com","sentAt":"2022-07-18T20:28:57Z","receivedAt":"2022-07-18T20:29:24Z","isPatch":false,"sender":{"key":"paul@kinzelman.com","avatar":null},"body":"I'm using git version 2.37.1.windows.1 and Windows 10\n\nI've got two systems which are miles apart and so are not on the same\nLAN, and I have connected them together using the ui.com VPN and M$\nRDP/TSclient. I mapped each system's C: drive to be accessed by the\nother system as Drive X: and I can transfer files back and forth\ninitiated on each system.\n\nI can also see all the repository files on the source system, including\nthe tree of files under the .git directory. Note I had to unhide the\n.git folder so that I could see that folder from the other system.\n\nHowever, when I run 'git clone' on one system to get the repository from\nthe other system, git seems to think the repository on the other\nsystem is empty when it's not. As I said, I can even do a directory\nand see all the other files.\n\nAny suggestions would be appreciated. Thanks!\n-Paul Kinzelman, Peralta NM\n\n"},{"id":"459331","messageId":"b5931787-3589-102f-cfeb-caeb8a07e149@jeffhostetler.com","threadId":"58182","inReplyTo":"f946c577-d3d6-212c-cec5-a6c63856b77d@kinzelman.com","subject":"Re: Possible git bug when working with Microsoft Mapped drives","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2022-07-18T20:46:44Z","receivedAt":"2022-07-18T20:46:48Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 7/18/22 4:28 PM, Paul Kinzelman wrote:\n> I'm using git version 2.37.1.windows.1 and Windows 10\n> \n> I've got two systems which are miles apart and so are not on the same\n> LAN, and I have connected them together using the ui.com VPN and M$\n> RDP/TSclient. I mapped each system's C: drive to be accessed by the\n> other system as Drive X: and I can transfer files back and forth\n> initiated on each system.\n> \n> I can also see all the repository files on the source system, including\n> the tree of files under the .git directory. Note I had to unhide the\n> .git folder so that I could see that folder from the other system.\n> \n> However, when I run 'git clone' on one system to get the repository from\n> the other system, git seems to think the repository on the other\n> system is empty when it's not. As I said, I can even do a directory\n> and see all the other files.\n> \n> Any suggestions would be appreciated. Thanks!\n> -Paul Kinzelman, Peralta NM\n> \n\nI can't duplicate your setup, so I'll just speculate out loud\nhere.  I have to wonder if the \"X:\" drive letters are tricking\nGit to thinking that the remote instance is actually local and\nGit is trying to use some shortcuts. (For example, it might\nhardlink them rather than copy them on Linux.)\n\nSo I'm wondering if \"--no-local\" or \"--no-hardlinks\" or using\na file URL rather than a pathname might make it behave differently.\n\nAgain, this is just a guess.\n\nThere are also some GIT_TRACE* environment variables that might\nbe helpful if the above doesn't help.\n\nJeff\n\nhttps://git-scm.com/docs/git-clone\n\n"},{"id":"459333","messageId":"YtXS1s66fw/UCvLU@tapette.crustytoothpaste.net","threadId":"58182","inReplyTo":"b5931787-3589-102f-cfeb-caeb8a07e149@jeffhostetler.com","subject":"Re: Possible git bug when working with Microsoft Mapped drives","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-07-18T21:38:30Z","receivedAt":"2022-07-18T21:41:03Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-07-18 at 20:46:44, Jeff Hostetler wrote:\n> On 7/18/22 4:28 PM, Paul Kinzelman wrote:\n> > I'm using git version 2.37.1.windows.1 and Windows 10\n> > \n> > I've got two systems which are miles apart and so are not on the same\n> > LAN, and I have connected them together using the ui.com VPN and M$\n> > RDP/TSclient. I mapped each system's C: drive to be accessed by the\n> > other system as Drive X: and I can transfer files back and forth\n> > initiated on each system.\n> > \n> > I can also see all the repository files on the source system, including\n> > the tree of files under the .git directory. Note I had to unhide the\n> > .git folder so that I could see that folder from the other system.\n> > \n> > However, when I run 'git clone' on one system to get the repository from\n> > the other system, git seems to think the repository on the other\n> > system is empty when it's not. As I said, I can even do a directory\n> > and see all the other files.\n> \n> I can't duplicate your setup, so I'll just speculate out loud\n> here.  I have to wonder if the \"X:\" drive letters are tricking\n> Git to thinking that the remote instance is actually local and\n> Git is trying to use some shortcuts. (For example, it might\n> hardlink them rather than copy them on Linux.)\n> \n> So I'm wondering if \"--no-local\" or \"--no-hardlinks\" or using\n> a file URL rather than a pathname might make it behave differently.\n\nIt may also be the case that the remote file system lacks some\nfunctionality that Git needs.  For example, Windows can support mapping\nHTTP DAV resources as drives, but the DAV protocol is incapable of\nproviding certain operations that Git expects of a file system (Git\nroughly needs something that's POSIX compliant, but can paper over case\ninsensitivity) and thus such a disk simply can't work with Git.\n\nThis may end up looking like the file system is empty because, for\nexample, the function to query directory contents may return an error.\nThe contents may not actually be empty, but because they cannot be\nenumerated in the way Git needs them to be, it appears that way.\n\nAgain, I don't know if this is the case here, but you're the second\nperson recently to have seen problems with using RDP for this purpose.\nYou may wish to try SFTP, which should work (at least it does for Unix\nsystems), or possibly SMB/CIFS (which may or may not work, but I believe\nit typically does).\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"459337","messageId":"d4a77fd1-6be7-6466-8c94-6e2552184094@kinzelman.com","threadId":"58182","inReplyTo":"YtXS1s66fw/UCvLU@tapette.crustytoothpaste.net","subject":"Re: Possible git bug when working with Microsoft Mapped drives","fromName":"Paul Kinzelman","fromEmail":"paul@kinzelman.com","sentAt":"2022-07-18T21:55:50Z","receivedAt":"2022-07-18T21:55:56Z","isPatch":false,"sender":{"key":"paul@kinzelman.com","avatar":null},"body":"Thank you! Jeff was right on, but I didn't want to create extra noise\non the elist, so I replied just to him.\n\nHis suggestion of the --no-hardlinks\ncaused it to work!\n\nMight be good to test to see if a drive letter is on a remote system\nand do that automagically.\n\nOn 7/18/2022 3:38 PM, brian m. carlson wrote:\n> On 2022-07-18 at 20:46:44, Jeff Hostetler wrote:\n>> On 7/18/22 4:28 PM, Paul Kinzelman wrote:\n>>> I'm using git version 2.37.1.windows.1 and Windows 10\n>>>\n>>> I've got two systems which are miles apart and so are not on the same\n>>> LAN, and I have connected them together using the ui.com VPN and M$\n>>> RDP/TSclient. I mapped each system's C: drive to be accessed by the\n>>> other system as Drive X: and I can transfer files back and forth\n>>> initiated on each system.\n>>>\n>>> I can also see all the repository files on the source system, including\n>>> the tree of files under the .git directory. Note I had to unhide the\n>>> .git folder so that I could see that folder from the other system.\n>>>\n>>> However, when I run 'git clone' on one system to get the repository from\n>>> the other system, git seems to think the repository on the other\n>>> system is empty when it's not. As I said, I can even do a directory\n>>> and see all the other files.\n>> I can't duplicate your setup, so I'll just speculate out loud\n>> here.  I have to wonder if the \"X:\" drive letters are tricking\n>> Git to thinking that the remote instance is actually local and\n>> Git is trying to use some shortcuts. (For example, it might\n>> hardlink them rather than copy them on Linux.)\n>>\n>> So I'm wondering if \"--no-local\" or \"--no-hardlinks\" or using\n>> a file URL rather than a pathname might make it behave differently.\n> It may also be the case that the remote file system lacks some\n> functionality that Git needs.  For example, Windows can support mapping\n> HTTP DAV resources as drives, but the DAV protocol is incapable of\n> providing certain operations that Git expects of a file system (Git\n> roughly needs something that's POSIX compliant, but can paper over case\n> insensitivity) and thus such a disk simply can't work with Git.\n>\n> This may end up looking like the file system is empty because, for\n> example, the function to query directory contents may return an error.\n> The contents may not actually be empty, but because they cannot be\n> enumerated in the way Git needs them to be, it appears that way.\n>\n> Again, I don't know if this is the case here, but you're the second\n> person recently to have seen problems with using RDP for this purpose.\n> You may wish to try SFTP, which should work (at least it does for Unix\n> systems), or possibly SMB/CIFS (which may or may not work, but I believe\n> it typically does).\n\n"},{"id":"459459","messageId":"e39ce708-afbf-4524-187c-20dcd979a061@jeffhostetler.com","threadId":"58182","inReplyTo":"d4a77fd1-6be7-6466-8c94-6e2552184094@kinzelman.com","subject":"Re: Possible git bug when working with Microsoft Mapped drives","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2022-07-19T21:02:10Z","receivedAt":"2022-07-19T21:02:15Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"Could you maybe create an issue against GFW for this so that we don't\nforget about it?\n\nhttps://github.com/git-for-windows/git/issues\n\nJeff\n\n\nOn 7/18/22 5:55 PM, Paul Kinzelman wrote:\n> Thank you! Jeff was right on, but I didn't want to create extra noise\n> on the elist, so I replied just to him.\n> \n> His suggestion of the --no-hardlinks\n> caused it to work!\n> \n> Might be good to test to see if a drive letter is on a remote system\n> and do that automagically.\n> \n> On 7/18/2022 3:38 PM, brian m. carlson wrote:\n>> On 2022-07-18 at 20:46:44, Jeff Hostetler wrote:\n>>> On 7/18/22 4:28 PM, Paul Kinzelman wrote:\n>>>> I'm using git version 2.37.1.windows.1 and Windows 10\n>>>>\n>>>> I've got two systems which are miles apart and so are not on the same\n>>>> LAN, and I have connected them together using the ui.com VPN and M$\n>>>> RDP/TSclient. I mapped each system's C: drive to be accessed by the\n>>>> other system as Drive X: and I can transfer files back and forth\n>>>> initiated on each system.\n>>>>\n>>>> I can also see all the repository files on the source system, including\n>>>> the tree of files under the .git directory. Note I had to unhide the\n>>>> .git folder so that I could see that folder from the other system.\n>>>>\n>>>> However, when I run 'git clone' on one system to get the repository \n>>>> from\n>>>> the other system, git seems to think the repository on the other\n>>>> system is empty when it's not. As I said, I can even do a directory\n>>>> and see all the other files.\n>>> I can't duplicate your setup, so I'll just speculate out loud\n>>> here.  I have to wonder if the \"X:\" drive letters are tricking\n>>> Git to thinking that the remote instance is actually local and\n>>> Git is trying to use some shortcuts. (For example, it might\n>>> hardlink them rather than copy them on Linux.)\n>>>\n>>> So I'm wondering if \"--no-local\" or \"--no-hardlinks\" or using\n>>> a file URL rather than a pathname might make it behave differently.\n>> It may also be the case that the remote file system lacks some\n>> functionality that Git needs.  For example, Windows can support mapping\n>> HTTP DAV resources as drives, but the DAV protocol is incapable of\n>> providing certain operations that Git expects of a file system (Git\n>> roughly needs something that's POSIX compliant, but can paper over case\n>> insensitivity) and thus such a disk simply can't work with Git.\n>>\n>> This may end up looking like the file system is empty because, for\n>> example, the function to query directory contents may return an error.\n>> The contents may not actually be empty, but because they cannot be\n>> enumerated in the way Git needs them to be, it appears that way.\n>>\n>> Again, I don't know if this is the case here, but you're the second\n>> person recently to have seen problems with using RDP for this purpose.\n>> You may wish to try SFTP, which should work (at least it does for Unix\n>> systems), or possibly SMB/CIFS (which may or may not work, but I believe\n>> it typically does).\n> \n"},{"id":"459487","messageId":"7391734b-c5d7-1f8c-912b-a75833a3070a@kinzelman.com","threadId":"58182","inReplyTo":"e39ce708-afbf-4524-187c-20dcd979a061@jeffhostetler.com","subject":"Re: Possible git bug when working with Microsoft Mapped drives","fromName":"Paul Kinzelman","fromEmail":"paul@kinzelman.com","sentAt":"2022-07-19T23:57:44Z","receivedAt":"2022-07-19T23:58:57Z","isPatch":false,"sender":{"key":"paul@kinzelman.com","avatar":null},"body":"I'm trying, but their 2FA won't work for me. I'm not getting their\nemail (yes I checked junk and spam) and there doesn't seem to\nbe a PC based alternative. I don't want to install another phone app.\n\nOn 7/19/2022 3:02 PM, Jeff Hostetler wrote:\n> Could you maybe create an issue against GFW for this so that we don't\n> forget about it?\n>\n> https://github.com/git-for-windows/git/issues\n>\n> Jeff\n>\n>\n> On 7/18/22 5:55 PM, Paul Kinzelman wrote:\n>> Thank you! Jeff was right on, but I didn't want to create extra noise\n>> on the elist, so I replied just to him.\n>>\n>> His suggestion of the --no-hardlinks\n>> caused it to work!\n>>\n>> Might be good to test to see if a drive letter is on a remote system\n>> and do that automagically.\n>>\n>> On 7/18/2022 3:38 PM, brian m. carlson wrote:\n>>> On 2022-07-18 at 20:46:44, Jeff Hostetler wrote:\n>>>> On 7/18/22 4:28 PM, Paul Kinzelman wrote:\n>>>>> I'm using git version 2.37.1.windows.1 and Windows 10\n>>>>>\n>>>>> I've got two systems which are miles apart and so are not on the same\n>>>>> LAN, and I have connected them together using the ui.com VPN and M$\n>>>>> RDP/TSclient. I mapped each system's C: drive to be accessed by the\n>>>>> other system as Drive X: and I can transfer files back and forth\n>>>>> initiated on each system.\n>>>>>\n>>>>> I can also see all the repository files on the source system, \n>>>>> including\n>>>>> the tree of files under the .git directory. Note I had to unhide the\n>>>>> .git folder so that I could see that folder from the other system.\n>>>>>\n>>>>> However, when I run 'git clone' on one system to get the \n>>>>> repository from\n>>>>> the other system, git seems to think the repository on the other\n>>>>> system is empty when it's not. As I said, I can even do a directory\n>>>>> and see all the other files.\n>>>> I can't duplicate your setup, so I'll just speculate out loud\n>>>> here.  I have to wonder if the \"X:\" drive letters are tricking\n>>>> Git to thinking that the remote instance is actually local and\n>>>> Git is trying to use some shortcuts. (For example, it might\n>>>> hardlink them rather than copy them on Linux.)\n>>>>\n>>>> So I'm wondering if \"--no-local\" or \"--no-hardlinks\" or using\n>>>> a file URL rather than a pathname might make it behave differently.\n>>> It may also be the case that the remote file system lacks some\n>>> functionality that Git needs.  For example, Windows can support mapping\n>>> HTTP DAV resources as drives, but the DAV protocol is incapable of\n>>> providing certain operations that Git expects of a file system (Git\n>>> roughly needs something that's POSIX compliant, but can paper over case\n>>> insensitivity) and thus such a disk simply can't work with Git.\n>>>\n>>> This may end up looking like the file system is empty because, for\n>>> example, the function to query directory contents may return an error.\n>>> The contents may not actually be empty, but because they cannot be\n>>> enumerated in the way Git needs them to be, it appears that way.\n>>>\n>>> Again, I don't know if this is the case here, but you're the second\n>>> person recently to have seen problems with using RDP for this purpose.\n>>> You may wish to try SFTP, which should work (at least it does for Unix\n>>> systems), or possibly SMB/CIFS (which may or may not work, but I \n>>> believe\n>>> it typically does).\n>>\n\n"}]}