Change:
if (parsedLine.type === 'match') { const matchPath = bytesOrTextToString(parsedLine.data.path); <del> const uri = URI.file(path.join(this.rootFolder, matchPath)); </del> <ins> const uri = URI.joinPath(this.root, matchPath); </ins> const result = this.createTextSearchMatch(parsedLine.data, uri); this.onResult(result);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: ` Steps to Reproduce: Calling on  returns the Windows drive letter "as is" (in my case, the drive letter is uppercase). For instance: However, returns a list of URI with the Windows drive letter as lowercase. For instance: Windows is case-insensitive but I think it would be better to return normalized URIs (or at least return a consistent value across APIs)
I just noticed that will apply lowercase on path segments (on Windows): Is that expected?
Regarding my last comment, it seems related to: since VS Code is using (which relies on posix path):
The URI implementation preserves the case of the path component, a normalized variant is being offered via . Tho, I wonder why this is needed or how this came up? Do you use to feed data into the UI or why is this an issue for you?
I'm using and I want to know if one URI is a child of another URI (i.e., path starts with). Since string comparison is case-sensitive, that's an issue. Basically, I have a list of URIs that comes from , and . I would expect to preserve the case of the path component but that's not the case. I read somewhere that paths should only be compared after calling on them () that's why I was suggesting to normalize path. However, since all URIs come from the API, it would be great if the case was preserved on all As an alternative, the URI module could provide functions to compare URIs (which will be case-insensitive on Windows).

In summary, the following function does the right thing (i.e., it preserves the case of the path component): The following function normalizes Windows drive letter to lowercase: In my opinion, should preserve Windows driver letter case. In this case, should be . The following function normalizes path segments: I think it would be better to preserve case on path segments.
It's worth noting that I can reproduce this issue on GitHub Actions but on my local machine (where my drive is C:) I get lowercase c: when calling
Are you brave enough now?
The following function returns the driver letter as is: Since the Windows driver letter is already in lowercase in other parts or the API, I think it would be great if the Windows driver letter returned by and was also in lowercase. In the meantime, I will use a wrapper around the API to lowercase Windows drive letter:
How and where does search construct its result uris? Do you use the uri identify service and do you create uri from absolute (file) paths or does rg return relative paths that you join with some uri?
Fiddling with the drive letter casing will only help you so much. All parts of the path can be in funny and expected casings and that's totally valid (wrt the OS). What we try to do is that the first appearance of an uri defines its shape and latter appearances are normalised to that. However, it only works with full uris and not containment, e.g defines the appearance and becomes that, however is included by that logic
We seem to join a path from rg to another root URI. I believe that these root URIs source all the way back here: So I use .
I believe this is the bug The variable is used as when creating . Because it is created via the drive letter is lower-cased. This shouldn't be done. The simplest is to create the parser with the URI and to use to create the resulting uri values and
Thanks and
andreamah/issue194692
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!