{"thread":{"id":"53864","subject":"Git bug - Windows subst/net use, Windows drive letter prefix","startedAt":"2020-07-16T11:03:25Z","lastAt":"2020-07-20T07:37:24Z","messageCount":3,"participants":["Paul D. Smith","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"401624","messageId":"DM6PR02MB5276FB15B1E9E66E98A0B7AFBD7F0@DM6PR02MB5276.namprd02.prod.outlook.com","threadId":"53864","inReplyTo":"DM6PR02MB52769C88FFC893FE3D44E901BD7F0@DM6PR02MB5276.namprd02.prod.outlook.com","subject":"Git bug - Windows subst/net use, Windows drive letter prefix","fromName":"Paul D. Smith","fromEmail":"paul.d.smith@metaswitch.com","sentAt":"2020-07-16T11:03:22Z","receivedAt":"2020-07-16T11:03:25Z","isPatch":false,"sender":{"key":"paul.d.smith@metaswitch.com","avatar":null},"body":"I believe there is a subtle bug in Git that can mean that a \"git add\" fails, complaining that \"fatal: <filename>: '<filename>' is outside repository at '//<server>/<share>/<directory> /'\n\nIt may be possible to reproduce this with simpler steps, but this is what I have that fails.\n\n1. A Git repo on system <server> below directory <directory> that can be reached via the Windows share <share>\n2. On a second system, perform \"net use z: file://%3cserver%3e/%3cshare>\"\n3. Now you can \"cd /d z:\\<directory>\" and run \"git status\" quite happily \n4. At this point I can also so this:\n\ta. \"cd /d z:\" then \"git add <z:\\some-changed-file>\"\n\t\ti. Note the drive letter prefixing the full-filename\n5. Now do a subst or a net use as follows:\n\ta. subst v: z:\\directory\n\tb. net use w: file://%3cserver%3e/%3cshare%3e/%3cdirectory>\n6. You can do both of these\n\ta. \"cd /d v:\" then \"git status\"\n\tb. \"cd /d w:\" then \"git status\"\n7. However both of these FAIL:\n\ta. \"cd /d v:\" then \"git add <v:\\some-changed-file>\"\n\tb. \"cd /d w:\" then \"git add <w:\\some-changed-file>\"\n\t\ti. Note the drive letter prefixing the full-filename\n8. Performing the above requests WITHOUT the drive letter prefixing the filename works!\n\nI assume that this is supposed to work and there is some subtle error merging the repository root and the filename-with-drive-prefix.\n\nRegards,\nPaul D.Smith.\n\n\n\n\n\n\n"},{"id":"401754","messageId":"20200719063156.rm6tr3m43enxsxg4@tb-raspi4","threadId":"53864","inReplyTo":"DM6PR02MB5276FB15B1E9E66E98A0B7AFBD7F0@DM6PR02MB5276.namprd02.prod.outlook.com","subject":"Re: Git bug - Windows subst/net use, Windows drive letter prefix","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2020-07-19T06:31:56Z","receivedAt":"2020-07-19T06:35:31Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Jul 16, 2020 at 11:03:22AM +0000, Paul D. Smith wrote:\n> I believe there is a subtle bug in Git that can mean that a \"git add\" fails, complaining that \"fatal: <filename>: '<filename>' is outside repository at '//<server>/<share>/<directory> /'\n>\n> It may be possible to reproduce this with simpler steps, but this is what I have that fails.\n>\n> 1. A Git repo on system <server> below directory <directory> that can be reached via the Windows share <share>\n> 2. On a second system, perform \"net use z: file://%3cserver%3e/%3cshare>\"\n> 3. Now you can \"cd /d z:\\<directory>\" and run \"git status\" quite happily\n> 4. At this point I can also so this:\n> \ta. \"cd /d z:\" then \"git add <z:\\some-changed-file>\"\n> \t\ti. Note the drive letter prefixing the full-filename\n> 5. Now do a subst or a net use as follows:\n> \ta. subst v: z:\\directory\n> \tb. net use w: file://%3cserver%3e/%3cshare%3e/%3cdirectory>\n> 6. You can do both of these\n> \ta. \"cd /d v:\" then \"git status\"\n> \tb. \"cd /d w:\" then \"git status\"\n> 7. However both of these FAIL:\n> \ta. \"cd /d v:\" then \"git add <v:\\some-changed-file>\"\n> \tb. \"cd /d w:\" then \"git add <w:\\some-changed-file>\"\n> \t\ti. Note the drive letter prefixing the full-filename\n> 8. Performing the above requests WITHOUT the drive letter prefixing the filename works!\n>\n> I assume that this is supposed to work and there is some subtle error merging the repository root and the filename-with-drive-prefix.\n>\n> Regards,\n> Paul D.Smith.\n>\n\nThanks for reporting your issue.\nIt's good to get well-written reports like this.\n\nAs a general note, this is specific to the \"Git for Windows\" project,\nand issues can be reported there:\nhttps://github.com/git-for-windows/git\n\nMore specific, I could reproduce the issue without using a network:\n\nC:\ncd Users/tb\nmkdir 200719-git-test-subst\ncd 200719-git-test-subst\ngit init\necho FILE >FILE.txt\n\nNow I can use\ngit add C:\\Users\\tb\\200719-git-test-subst\\FILE.txt\n\nThat surborised me a little bit, since an absolute path name was given to Git.\nHowever, Git is able to figure out, that\n\nC:\\Users\\tb\\200719-git-test-subst\\FILE.txt\nis the same as\nFILE.txt\n\nas you can see running\ngit ls-files\n\nThe file names (and path components) in Git are always tracked \"relative\".\nRelative to the root of the Git repo.\nAnd here Git translates\n\"C:\\Users\\tb\\200719-git-test-subst\\FILE.txt\" into \"FILE.txt\"\n\nIn that sense, drive letters are not trackesd at all, you can clone that repo to any drive\nletter, or even to a network share.\n\nIf I now use\nsubst T: C:\\Users\\tb\\200719-git-test-subst\n\nI can use the same repo under T:\\\n\nfile/path names are still relative, so if you change into T:\\\nand run\ngit ls-files\nyou will still see FILE.txt\n\nNow mixing those 2 does not work.\nGit is unable to figure out the \"T:\\\" is the same as \"C:\\Users\\tb\\200719-git-test-subst\"\n\nIn general, different drive letters host different file systems, so Git assumes that\nthey don't point to the same directory.\n\nAdding this functionality may be possible, I don't know the Windows APIs good enough.\nBut:\nThat will cost sone time (in terms of development) and give a run-time penalty for\nGit itself for many Git invocations.\nIt may even open up for security issues, since the \"check if X: is the same as Y:\"\nneeds to be done in one step, and the the operation needs to be done in the next\nstep, opening a small timing window, where bad things may happen.\n\nThis was my limited view on how things work, there may be details missed (or wrong).\n\n\n\n\n"},{"id":"401762","messageId":"DM6PR02MB52762B22764F080837CF971FBD7B0@DM6PR02MB5276.namprd02.prod.outlook.com","threadId":"53864","inReplyTo":"20200719063156.rm6tr3m43enxsxg4@tb-raspi4","subject":"RE: Git bug - Windows subst/net use, Windows drive letter prefix","fromName":"Paul D. Smith","fromEmail":"paul.d.smith@metaswitch.com","sentAt":"2020-07-20T07:37:19Z","receivedAt":"2020-07-20T07:37:24Z","isPatch":false,"sender":{"key":"paul.d.smith@metaswitch.com","avatar":null},"body":"-----Original Message-----\nFrom: Torsten Bögershausen <tboegi@web.de> \nSent: 19 July 2020 07:32\nTo: Paul D. Smith <Paul.D.Smith@metaswitch.com>\nCc: git@vger.kernel.org\nSubject: Re: Git bug - Windows subst/net use, Windows drive letter prefix\n\nNOTE: Message is from an external sender\n\nOn Thu, Jul 16, 2020 at 11:03:22AM +0000, Paul D. Smith wrote:\n> I believe there is a subtle bug in Git that can mean that a \"git add\" fails, complaining that \"fatal: <filename>: '<filename>' is outside repository at '//<server>/<share>/<directory> /'\n>\n> It may be possible to reproduce this with simpler steps, but this is what I have that fails.\n>\n> 1. A Git repo on system <server> below directory <directory> that can \n> be reached via the Windows share <share> 2. On a second system, perform \"net use z: file://%3cserver%3e/%3cshare>\"\n> 3. Now you can \"cd /d z:\\<directory>\" and run \"git status\" quite \n> happily 4. At this point I can also so this:\n>       a. \"cd /d z:\" then \"git add <z:\\some-changed-file>\"\n>               i. Note the drive letter prefixing the full-filename 5. \n> Now do a subst or a net use as follows:\n>       a. subst v: z:\\directory\n>       b. net use w: file://%3cserver%3e/%3cshare%3e/%3cdirectory>\n> 6. You can do both of these\n>       a. \"cd /d v:\" then \"git status\"\n>       b. \"cd /d w:\" then \"git status\"\n> 7. However both of these FAIL:\n>       a. \"cd /d v:\" then \"git add <v:\\some-changed-file>\"\n>       b. \"cd /d w:\" then \"git add <w:\\some-changed-file>\"\n>               i. Note the drive letter prefixing the full-filename 8. \n> Performing the above requests WITHOUT the drive letter prefixing the filename works!\n>\n> I assume that this is supposed to work and there is some subtle error merging the repository root and the filename-with-drive-prefix.\n>\n> Regards,\n> Paul D.Smith.\n>\n\nThanks for reporting your issue.\nIt's good to get well-written reports like this.\n\nAs a general note, this is specific to the \"Git for Windows\" project, and issues can be reported there:\nhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgit-for-windows%2Fgit&amp;data=02%7C01%7CPaul.D.Smith%40metaswitch.com%7C62bef1d2ef71432c41da08d82bad70d9%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C1%7C637307371245564042&amp;sdata=qFq0Fqg5Vjx1w9rYk55fcwYcNvEP0Z5W0MXvFrMuuys%3D&amp;reserved=0\n\nMore specific, I could reproduce the issue without using a network:\n\nC:\ncd Users/tb\nmkdir 200719-git-test-subst\ncd 200719-git-test-subst\ngit init\necho FILE >FILE.txt\n\nNow I can use\ngit add C:\\Users\\tb\\200719-git-test-subst\\FILE.txt\n\nThat surborised me a little bit, since an absolute path name was given to Git.\nHowever, Git is able to figure out, that\n\nC:\\Users\\tb\\200719-git-test-subst\\FILE.txt\nis the same as\nFILE.txt\n\nas you can see running\ngit ls-files\n\nThe file names (and path components) in Git are always tracked \"relative\".\nRelative to the root of the Git repo.\nAnd here Git translates\n\"C:\\Users\\tb\\200719-git-test-subst\\FILE.txt\" into \"FILE.txt\"\n\nIn that sense, drive letters are not trackesd at all, you can clone that repo to any drive letter, or even to a network share.\n\nIf I now use\nsubst T: C:\\Users\\tb\\200719-git-test-subst\n\nI can use the same repo under T:\\\n\nfile/path names are still relative, so if you change into T:\\ and run git ls-files you will still see FILE.txt\n\nNow mixing those 2 does not work.\nGit is unable to figure out the \"T:\\\" is the same as \"C:\\Users\\tb\\200719-git-test-subst\"\n\nIn general, different drive letters host different file systems, so Git assumes that they don't point to the same directory.\n\nAdding this functionality may be possible, I don't know the Windows APIs good enough.\nBut:\nThat will cost sone time (in terms of development) and give a run-time penalty for Git itself for many Git invocations.\nIt may even open up for security issues, since the \"check if X: is the same as Y:\"\nneeds to be done in one step, and the the operation needs to be done in the next step, opening a small timing window, where bad things may happen.\n\nThis was my limited view on how things work, there may be details missed (or wrong).\n\n----------\nTorsten,\n\nThanks for the response.  It's not an important bug for me now that I know what is going on; I was able to rewrite the code I inherited slightly to avoid problems.\n\nIf there is a sensible place to put it, it might be good to document this effect; I don't know if there is any way that it could be mentioned in the error text when commands fail as a \"Are you doing this?\" hint to users?\n\nRegards,\nPaul D.Smith\n"}]}