Bug: Creating a file with the same name but different casing causes the adjacent directory to have the wrong icon

[sbrl]

I think I've found a bug in file-icons. Consider the following directory structure:

root
  + SomeTest
       + something.txt
  + sometest

Where SomeTest is a directory some something in it, and sometest is a file with the following contents:

#!/usr/bin/env bash

echo "This is a test";

The file sometest is correctly assigned the shell script icon based on the shebang at the top. However, the directory SomeTest is also wrongly assigned the shell script icon too!

This is, of course, a bug that is not reproducible on Windows - as Windows has a case-insensitive filesystem which wouldn't allow the above directory structure in the first place. To this end, a Linux machine is required to reproduce this bug.

[Alhadis]

TL;DR: Run file-icons:clear-cache, collapse the parent folder, then reopen it to force a refresh.

This is a known issue with the package's current API; specifically, its filesystem layer that's making synchronous lstat calls that inevitably lead to race conditions when filetypes are changed outside the Atom process (and by "filetype", I mean directory ↔ file ↔ symlink).

The API relies on the initial lstat call being synchronous, due to the need to distinguish between "directory" icons and "file" icons (due to how our filetype/icon-pairing strategies are implemented). Making it fully async is something I've been planning to do, but it involves rewriting the entire damn API due to it depending too strongly on knowing the entity-type up-front (directory/file/symlink).

Now, as this issue isn't an urgent one, and the package is currently stable save for a few rough-edges, I'm in no hurry to tear half of it up and rewrite it in order to fix this.

[Alhadis]

I'll leave this issue here instead of migrate it to file-icons/fs (where similar reports have been moved), so that other users will hopefully find the issue+explanation easier. 👍

[sbrl]

Ah, I see! Thanks for the explanation :-)