GIT: Unsafe repository 'Mark as Safe' for UNC paths missing needed prefix in configuration.

[msftrncs]

Does this issue occur when all extensions are disabled?: N/A, extensions are required.

Version: 1.74.0 (user setup) Commit: 5235c6bb189b60b01b1f49062f4ffa42384f8c91 Date: 2022-12-05T16:38:16.075Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0.19045 Sandboxed: No

Steps to Reproduce:

1. Open a network UNC based workspace with a GIT repository that is not currently marked safe.
2. Activate the process to mark the repository safe via the new feature.

The repository still will not work. Looking at the .gitconfig file will show that the UNC path was added to the safe directory list without the needed %(prefix)/ prefix.

[lszomoru]

@msftrncs, do you mind sharing the exact output when running git status inside the unsafe repository as well as the exact path that is being added to the gitconfig file? I am asking as we are currently extracting the path from the output of the git status command so the issue could be upstream. Thank you!

[msftrncs]

Here is an example ... I've removed details such as the SID's for security:

fatal: detected dubious ownership in repository at '//RK-VS-FS1/Users Folders/cmorris/My Documents/Projects/Aerial Programming/2020-12 ItvlSync - Double Air Alarm'        
'//RK-VS-FS1/Users Folders/cmorris/My Documents/Projects/Aerial Programming/2020-12 ItvlSync - Double Air Alarm' is owned by:
        ''
but the current user is:
        ''
To add an exception for this directory, call:

        git config --global --add safe.directory '%(prefix)///RK-VS-FS1/Users Folders/cmorris/My Documents/Projects/Aerial Programming/2020-12 ItvlSync - Double Air Alarm'

Note the suggested command to add the path to the safe.directory list includes the needed %(prefix)/ prefix, but its possible that this is something specific to 'Git for Windows'?

This is my personal documents folder via Folder Redirection, its stored on a network path, and since I am the systems administrator, my files are all owned by the administrator, thus ALL my repositories no matter where they are, are considered unsafe. :(

[lszomoru]

@msftrncs, thank you very much! I was extracting the path from the first line of the output which is not correct. Will work on a fix.

[msftrncs]

You might also note, GIT seems to also flip back and forth as to whether the server in the UNC path should be all capitalized or all lowercase. Don't know if it is something VSCode is doing that causes that, but it can change its mind between two sessions even though the case of the path doesn't change from what I can see in VSCode. This causes an already marked safe repository to be marked unsafe, which is exactly what happened here.

[lszomoru]

You might also note, GIT seems to also flip back and forth as to whether the server in the UNC path should be all capitalized or all lowercase. Don't know if it is something VSCode is doing that causes that, but it can change its mind between two sessions even though the case of the path doesn't change from what I can see in VSCode. This causes an already marked safe repository to be marked unsafe, which is exactly what happened here.

@msftrncs, could you please expand on that? Are you seeing this casing issue in the git output window or VS Code UI?

[msftrncs]

Depends on where you look. So far today, VSCode's Explorer is indicating the path's server portion as uppercase and the source control is also reporting the server portion as uppercase (hover over a repository), so they are agreeing, but next week or next month, it will switch and they won't agree, and it usually is GIT that has changed, not what VSCode shows in the Explorer view. (Explorer view)

(source control view)

I've been trying to track this down for a long while, and now the safe-repository mechanism also gets tripped up in this.

[lszomoru]

@msftrncs, thanks for the example. I would suggest that you keep an eye out for any discrepancies on the casing of the path and file a separate issue when it occurs again. As far as this particular issue goes, the fix will be available with the Insiders release next week.