New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with not case/fragment-normalizing file paths (macOS, Windows) #12448

bpasero opened this Issue Sep 22, 2016 · 55 comments


None yet

bpasero commented Sep 22, 2016

In VS Code we deal with resource URIs across all layers. In most cases we use URI.toString() to decide if a resource is equal to another resource. This assumption is not very good when we talk about file system paths because on macOS and Windows a file path should be considered equal if the paths are identical, even if the casing differs (/some/path === /SOME/path). Only Linux has a case-sensitive file system where this rule does not apply.

This leads to numerous related issues:

@bpasero bpasero added the bug label Sep 22, 2016

@bpasero bpasero added this to the Backlog milestone Sep 22, 2016

@bpasero bpasero self-assigned this Sep 22, 2016

@bpasero bpasero changed the title from Issues when using wrong path casing when starting Code to Issues with mixed casing of file paths entering the workbench Jan 3, 2017

@bpasero bpasero changed the title from Issues with mixed casing of file paths entering the workbench to Issues with not case-normalizing file paths (macOS, Windows) Jan 3, 2017

@bpasero bpasero added the debt label Feb 4, 2017


This comment has been minimized.


bpasero commented Feb 6, 2017

Pushed a fix for the broken file events on macOS.

@bpasero bpasero changed the title from Issues with not case-normalizing file paths (macOS, Windows) to Issues with not case/fragment-normalizing file paths (macOS, Windows) Feb 7, 2017


This comment has been minimized.

BillDenton commented Mar 2, 2017

Any update on this? I keep tripping over it particularly when using the debugger.

@bpasero bpasero modified the milestones: March 2017, Backlog Mar 16, 2017

bpasero added a commit that referenced this issue Mar 16, 2017


This comment has been minimized.

majelbstoat commented Jul 11, 2018

Yeah, echoing the same as @vvs. In addition, this also appears to cause .eslintignore rules not to be respected when a file is opened through jump to definition as an all lowercase path, which means code inside node_modules is being linted. Furthermore cmd+shift+e to show the file in explorer does not work.

I feel like I've noticed this a lot more since Typescript 2.9's --declarationMap changes which means I'm jumping directly into the .ts files, rather than jumping to the d.ts file and opening the code file manually?


This comment has been minimized.

decimad commented Jul 25, 2018

Hello, what is the state of this "bug" really? Are the devs considering this to be a non-issue rather related to the various extensions that passed by referencing it? Many subsequently closed the issues with a fix in the extension itself, seemingly, so maybe this all is not vscode's problem?


This comment has been minimized.

majelbstoat commented Jul 25, 2018

@decimad here is at least one example where the extension author does not believe they can solve it independently of this problem: Microsoft/vscode-eslint#503 (comment)


This comment has been minimized.


0xabu commented Jul 25, 2018

I have this problem with the $mscompile problem matcher in tasks.json, which AFAIK is core functionality and not part of any extension. #18684 describes the same problem, and was duped here.


This comment has been minimized.

gitsupersmecher commented Aug 7, 2018

This issue started to happened with the last update non-stop. I use typescript + tsc and VS Code started to be unusable; it cannot find any reference because of the path casing issue. Could you please look into this issue? This became a serious issue for using VS Code for us.


This comment has been minimized.

Boddlnagg commented Sep 5, 2018

This issue has been open for almost two years now and duplicates are opened (and subsequently closed as duplicates) on a regular basis. Could we have an update about the status? Is someone looking into this?


This comment has been minimized.

sag1v commented Sep 8, 2018

For me it was a wrong import.
i had a file which i may or may not changed its name, lets say it's called MyComponent.
I got a warning that i have duplicate files that only differs in casing:
MyComponent -> MyCOmponent.
Well it turns out that i had a typo in one of my imports:

import MyComponent from './MyCOmponent`;

After i fixed the typo:

import MyComponent from './MyComponent`;

Everything worked well.

So just search (ctrl + f) your folders for the file name and make sure you don't have a typo somewhere.


This comment has been minimized.

StJohn3D commented Oct 9, 2018

Currently seeing this message:

[ts] File name 'C:/Users/me/project/_demo/src/components/utils/CodeBlock.tsx' differs from already included file name 'c:/Users/me/project/_demo/src/components/utils/CodeBlock.tsx' only in casing.
module "c:/Users/me/project/_demo/src/components/utils/CodeBlock"

The line of code that is getting the red underline in VS Code is this:

import { BlankPage } from '../../templates/BlankPage' //<--does not throw error
import { CodeBlock } from '../../utils/CodeBlock'  //<-- throws error

As you can see, the only difference is in the drive letter. C:/Users vs c:/Users, but I'm not setting that in my import since I'm just using a relative path. So something in VS Code is acting funny here.
Thankfully it still compiles on windows for me. But that error/red-underline only started showing up a few minutes ago after I closed-reopened VS Code and it updated to latest as of 10/09/2018


This comment has been minimized.

chongchai commented Nov 6, 2018

I get the same error when I open a C project with samba.
Each time I use 'go to definition', VSCode will open a file with upper case file name. But the real path is all low case.


This comment has been minimized.

admvx commented Nov 8, 2018

This is pretty specific, but in case it helps anyone, I also had this issue due to a task's custom problem matcher on Windows:

  • My external compiler refers to source paths weirdly, like: C:\some-dir\another-dir\..\another-dir\source.txt
  • In my task problem matcher, I initially used "fileLocation": "absolute"
  • Following links from the Problems panel, I would end up with duplicate tabs


  • Updating the problem matcher to use "fileLocation": ["relative", "/"] I guess tells vscode to pre-resolve any relative parts of the path (before deduping against open tabs), rather than taking the path at face value and letting the OS resolve the location.

This comment has been minimized.

ferdugong commented Dec 4, 2018

I'm having problems too related to this behaviour.
I suppose most of the people having this problems are programming on a case-insensitive filesystem (HFS+, APFS, NTFS) as myself.

This actually causes me problems while developing because when I'm capitalising a filename git won't recognise the change causing me the same error as @StJohn3D, because the import inside other files wouldn't match the case.

This is quite annoying and it would be nice if the editor when capitalising filenames could detect it as a normal filename change so that git can track it.

Is there any possibility this feature will ever be integrated?


This comment has been minimized.

cchamberlain commented Dec 7, 2018

This one has been driving us crazy for a while on Windows 10. I get this all the time #12448 (comment).

Makes files in sidebar red. When I use go to definition it opens a file with the lowercase name that doesn't actually exist. If I make edits to that version then go open the actual one with the right casing in the sidebar, it seems to merge types definitions between the two. I will get errors like "you can't add a duplicate member to this type with the same name".

This is my single biggest problem with VSCode and has been for some time.


This comment has been minimized.

tommitytom commented Dec 13, 2018

Can any dev respond to at least say why they are ignoring this issue? It's been open well over two years now and it's such a glaringly obvious bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment