View File History not working - absolute path used #1045
Comments
|
Please help, Don't know why diff suddenly stopped working when on UNC path Unable to open 'Test.ps1 (added in c9f4f86)': Unable to read file 'gitlens://c9f4f86/my.server.local/PsF/Scripts/Test/Test.ps1?{"path":"//my.server.local/PsF/Scripts/Test/Test.ps1","ref":"c9f4f8632dccbaf3f552103ea9f2f66ef5a4bcda","repoPath":"//my.server.local/PsF/Scripts/Test"}' (Error: Unable to resolve non-existing file 'gitlens://c9f4f86/my.server.local/PsF/Scripts/Test/Test.ps1?{"path":"//my.server.local/PsF/Scripts/Test/Test.ps1","ref":"c9f4f8632dccbaf3f552103ea9f2f66ef5a4bcda","repoPath":"//my.server.local/PsF/Scripts/Test"}'). |
|
Reverted VSCode from 1.46.1 to 1.45.1 and it started working again. Maybe something to do with this https://code.visualstudio.com/updates/v1_46#_file-path-casing? |
|
Same issue....this is what happens when I try to use the Compare feature:
Not an issue with my other machine that does not use UNC path. |
|
same here |
|
Hi, can someone please help with this? |
|
This issue also breaks breakpoint set (xdebug php). Them will not work until absolute path used while opening file. |
|
Well I switched to the "Git History" extension. I don't like the UI as much but at least it works. Maybe need some more time to get used to it. |
|
GitLens is unusable on network share / drive. Something is wrong with GitUri, inconsistent paths. UNC, Networkdrive and together. Sometimes authority=[commit hash]. Not correct? Ok, not my job, but I have simple workaround for compare... I have replaced one line in relativeFsPath(): You can replace files in GitLens extention dist folder with attached files. Tested with last portable git for windows on network share and network drive. |
|
Thank you @p3t3r5 your fixed version works for me |
|
gitlens-11.0.0-beta.1 works nice |
Not working for me, same error. |
|
Confirmed, gitlens-11.0.0-beta.1 not working with UNC Pathes, but it works on Network Drive |
|
11.0.1 is out but this issue still exists. |
eamodio
added
help-wanted
|
@mikes-gh If you are able to dig into it and provide a PR that would be greatly helpful |
|
@eamodio Happy to do PR I have spent a few hours looking.. It seems the gitlens document scheme doesn't play well with UNC. So when the uri is split the shortsha ends up being the authority and the path loses its double slash
Also could you explain this bit of code. It is in this area that I could potentially fix the Your input would greatly aid me in direction of the PR. |
|
HI, [2020-11-20 12:11:04:316] [e:/Data/Repos/myrepo] Git Command failed: C:\Program Files\Git\cmd\git.exe -c core.longpaths=true -c core.quotepath=false -c color.ui=false -c color.status=false status --porcelain=v2 --find-renames=10% -- v:/mp/portal/LightViewer/Client/JavaScript/LVClient/EngineLayer/SyncZP.js • v:/mp/portal/LightViewer/Client/JavaScript/LVClient/EngineLayer/SyncZP.js: 'v:/mp/portal/LightViewer/Client/JavaScript/LVClient/EngineLayer/SyncZP.js' is outside repository at 'E:/Data/Repos/myrepo' • 112 ms This used to work with the previous GitLens version and previous git version. You can check this out as well: However, things like adding and committing works in VSCode (I have 1.51) so I guess it somehow knows how to handle subst drives. Thanks! If I can do anything to help speed this along, I'd help. |
|
uri.fsPath in vscode wont play nicely with the short sha as the authority Not designed to work with gitslens scheme. |
|
Sorry for late response, I had a few busy days at work. This seems odd:
The actual git repository is k:\USER\Flo\Script\vs-konfiguration Behind the letter K: is a windows NAS, mapped using a UNC path. Here's the debug output:
|
|
Here's the debug output if opening the same git repository using the UNC path directly, not via the mapped drive. In this case everything works fine and the repository is correctly identified as root repository:
|
|
So, I cloned the repo and took a look. In this block The networkPath always resolves to the complete path as UNC path. It seems that this is due to the usage of fs.realpath.native instead of just fs.realpath as you do in the next block. The path returned from fs.realpath would be fine, but maybe you chose the .native method on purpose? In that case the replacement would need to be rephrased to only replace the part of the path that maps to the drive letter. |
… fs.realpath The previously used fs.realpath.native function returned UNC paths on Windows, even if the path is actually using a drive letter
Use fs.realpath to get a path starting with the drive letter for mapped drives. The previously used fs.realpath.native function returned UNC paths on Windows, even if the path is actually using a drive letter
|
I used What do you get if you run I've tried setting up a test -- file share from 1 machine to another, and I can't repro the issue you are seeing. Also what version of Git do you have? |
eamodio
removed
the
pending-release
I'll provide the answers to those questions once I'm back in office mid January. Git version was current at the time: 2.29.2.windows.2 |
|
Sounds good, thanks! |
Use fs.realpath to get a path starting with the drive letter for mapped drives. The previously used fs.realpath.native function returned UNC paths on Windows, even if the path is actually using a drive letter
Interesting. I deactivated GitLens and tried VS Code source control, same behavior for the mapped drive. Once we find out how to fix it for GitLens we should probably port the changes back to VS Code.
The mapped drive has a UNC path of
Debug output on Dec 8th used version 2.29.2.windows.2 Edit: Edit2: So the part is only relevant for repositories on mapped drives anyway, isn't it? |
|
Thanks for the information! I am really confused why |
|
I wonder if we use |
|
Also does it make any difference if you open VS Code with the path starting with |
I don't seem to can. Windows capitalizes the drive letter right away.
That may be a workaround, but let's keep that as a last resort.
I just checked out 3d1808b where the workaround for new git versions was first introduced. The code from this commit works. |
I think I found it. Let me run a few more tests to make sure it doesn't break anything and then you may get an update on the PR. |
fs.realpath.native in NodeJS uses the Win32 API function GetFinalPathNameByHandle() on Windows hosts, therefore a given path must follow the guidelines for Win32 API file functions. Drive letters on Windows need to end on a backslash according to the Win32 File Naming Conventions (https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file) Omitting the backslash results in Windows treating the remaining path components as a relative path starting from the current directory on the specified disk https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#fully-qualified-vs-relative-paths
|
Alright, this PR should do the trick #1334 I included some details about the issue in the commit message, but the important part to know is that I'm still wondering why it didn't show for your test file share, but maybe it's related to the special behavior with SMB? The drive I tested with is connected using SMB https://docs.microsoft.com/de-de/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew#remarks Let me know if I should create a PR for VS Code as well once you verified this |
|
Awesome work! Thank you so much -- tried it out and works great. I still wonder why I don't see the issue with my file shares, but If you'd like to open a PR for VS Code that would be great! |
fs.realpath.native in NodeJS uses the Win32 API function GetFinalPathNameByHandle() on Windows hosts, therefore a given path must follow the guidelines for Win32 API file functions. Drive letters on Windows need to end on a backslash according to the Win32 File Naming Conventions (https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file) Omitting the backslash results in Windows treating the remaining path components as a relative path starting from the current directory on the specified disk https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#fully-qualified-vs-relative-paths
|
Well, I guess I found out now. I forked VS Code to create the PR for it and wasn't able to reproduce the issue there (as the development VS Code was a fresh install without any extensions or settings modified yet). I'd still suggest to make the PR if you agree. After all this would be the right way to pass a drive letter to Win32 API functions according to the specification. |
|
Hrm, interesting. I would definitely still like to get the PR merged in VS Code since it is the correct usage and my guess is that there are probably more cases that cause the issue. Since this has come up lots of times on both repos since the git change and I've never been able to get to the bottom of it. Though it would be quite interesting to see why the GitLab extension causes it. |
|
Ok, forget about the |
|
There we go: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/302 If you want to take a look and share your insights that would be much appreciated. I don't have solid knowledge about how VS Code and its extensions are isolated process-wise. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This issue #932 seems to have come back.
The File History view no longer displays the commits for a file
even through as can be seen below, there are commits.
when you try to open it I get the following error
looks like it's using the absolute path.
The text was updated successfully, but these errors were encountered: