-----Original Message----- From: Torsten Bögershausen <tboegi@xxxxxx> Sent: 19 July 2020 07:32 To: Paul D. Smith <Paul.D.Smith@xxxxxxxxxxxxxx> Cc: git@xxxxxxxxxxxxxxx Subject: Re: Git bug - Windows subst/net use, Windows drive letter prefix NOTE: Message is from an external sender On Thu, Jul 16, 2020 at 11:03:22AM +0000, Paul D. Smith wrote: > 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> /' > > It may be possible to reproduce this with simpler steps, but this is what I have that fails. > > 1. A Git repo on system <server> below directory <directory> that can > be reached via the Windows share <share> 2. On a second system, perform "net use z: file://%3cserver%3e/%3cshare>" > 3. Now you can "cd /d z:\<directory>" and run "git status" quite > happily 4. At this point I can also so this: > a. "cd /d z:" then "git add <z:\some-changed-file>" > i. Note the drive letter prefixing the full-filename 5. > Now do a subst or a net use as follows: > a. subst v: z:\directory > b. net use w: file://%3cserver%3e/%3cshare%3e/%3cdirectory> > 6. You can do both of these > a. "cd /d v:" then "git status" > b. "cd /d w:" then "git status" > 7. However both of these FAIL: > a. "cd /d v:" then "git add <v:\some-changed-file>" > b. "cd /d w:" then "git add <w:\some-changed-file>" > i. Note the drive letter prefixing the full-filename 8. > Performing the above requests WITHOUT the drive letter prefixing the filename works! > > I assume that this is supposed to work and there is some subtle error merging the repository root and the filename-with-drive-prefix. > > Regards, > Paul D.Smith. > Thanks for reporting your issue. It's good to get well-written reports like this. As a general note, this is specific to the "Git for Windows" project, and issues can be reported there: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgit-for-windows%2Fgit&data=02%7C01%7CPaul.D.Smith%40metaswitch.com%7C62bef1d2ef71432c41da08d82bad70d9%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C1%7C637307371245564042&sdata=qFq0Fqg5Vjx1w9rYk55fcwYcNvEP0Z5W0MXvFrMuuys%3D&reserved=0 More specific, I could reproduce the issue without using a network: C: cd Users/tb mkdir 200719-git-test-subst cd 200719-git-test-subst git init echo FILE >FILE.txt Now I can use git add C:\Users\tb\200719-git-test-subst\FILE.txt That surborised me a little bit, since an absolute path name was given to Git. However, Git is able to figure out, that C:\Users\tb\200719-git-test-subst\FILE.txt is the same as FILE.txt as you can see running git ls-files The file names (and path components) in Git are always tracked "relative". Relative to the root of the Git repo. And here Git translates "C:\Users\tb\200719-git-test-subst\FILE.txt" into "FILE.txt" In that sense, drive letters are not trackesd at all, you can clone that repo to any drive letter, or even to a network share. If I now use subst T: C:\Users\tb\200719-git-test-subst I can use the same repo under T:\ file/path names are still relative, so if you change into T:\ and run git ls-files you will still see FILE.txt Now mixing those 2 does not work. Git is unable to figure out the "T:\" is the same as "C:\Users\tb\200719-git-test-subst" In general, different drive letters host different file systems, so Git assumes that they don't point to the same directory. Adding this functionality may be possible, I don't know the Windows APIs good enough. But: That will cost sone time (in terms of development) and give a run-time penalty for Git itself for many Git invocations. It may even open up for security issues, since the "check if X: is the same as Y:" needs 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. This was my limited view on how things work, there may be details missed (or wrong). ---------- Torsten, Thanks 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. If 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? Regards, Paul D.Smith
