Wrong icons and cannot open file

[kevinlieser]

I am on macOS running Atom 1.33.1.

When I close the Atom window and open it later for further work (on macOS it is not closed completely) sometimes (sporadically) the file icons are not correct (files have folder icon and some folder have a "document"(?) outline icon) and these files won't open (the files with the folder icon).

Then I need to restart Atom completely and the icons appear correct – but it's annoying – it happens 10 times a day for sure.

Attached two screen with wrong and correct folder icons.

It's just random which folders have this outljne icon – it's not the folders that are "open" even when it looks like this in the screen.

[Alhadis]

Hey @kevinlieser,

Could you give me a list of packages you have installed? Just copy the output of apm ls -ib will do.

Are there any error diagnostics being logged to the devtools console when files refuse to open? This is usually indicative that an exception was thrown and uncaught while attempting to open a file tab.

[kevinlieser]

I have another prob with the dev console – when I open it it crashes Atom and I need to "reload atom" but after that the Icons worked again ;-) Have no Idea why opening the dev console after launching atom crashes.

Here is the list of packages.

atom-autocomplete-php@0.25.6
atom-beautify@0.33.4
atom-prettify@0.1.3
atom-ternjs@0.19.1
autoclose-html@0.23.0
autocomplete-typo3-fluid@0.3.5
build@0.70.0
busy-signal@2.0.0
color-picker@2.3.0
dash-syntax@0.4.2
dash-ui@0.4.4
dbclick-tree-view@1.6.3
file-icons@2.1.30
fix-indent-on-paste@0.1.1
ghar-dark-syntax@2.0.0
glacier-dark-ui@1.5.0
ide-php@0.7.18
intentions@1.1.5
language-htaccess@0.2.0
language-typo3-fluid@0.2.1
language-typoscript@0.2.0
lessc-on-save@0.4.0
linter@2.3.0
linter-json-lint@0.1.3
linter-php@1.6.0
linter-ui-default@1.7.1
minimap@4.29.9
nv-dark-syntax@1.4.1
pigments@0.40.2
project-viewer@1.3.1
sass-autocompile@0.13.5
script@3.18.1
symbols-list@2.5.1
tree-view@0.224.5
tree-view-autoresize@2.3.0
zhk-dark-syntax@0.3.1

[Alhadis]

Wait, it crashes? What happens when you start Atom in dev mode? (command: atom -d /path/to/project).

This actually sounds like a problem with your Atom installation, which you should probably report upstream, not here. Note that a new Atom release was cut recently (v1.35.1), so I recommend you upgrade first.

[kevinlieser]

Upgraded to 1.35.1 now and opening the dev console do not crash – I will report if the icon bug also solved "itself". Thanks!

[Alhadis]

No error messages then? Does everything work fine if you boot in regular (non-dev) mode?

[kevinlieser]

Yes, at this point. But the problem only occured if I minimized Atom for a period of time and opened it to work again – so just if it was open for a longer time. I will report if any problems occur.

[kevinlieser]

Got a wrong Icon again. Outline folder icon. Opened the Dev console, but crashed again. Attached a screen how it looked like when it crashed.

Also disabled atom-ternjs package temporarily.

[Alhadis]

Okay, this is because Atom's failing to start, indicating a serious error that's far beyond the scope of this package. You need to report this upstream.

This can affect file-icons because if something breaks during package activation (i.e., during start-up), packages which have already started initialising will break, hard.

[kevinlieser]

But the error / crash only occur if I open the dev console – just to be clear :-)

[Alhadis]

Either way, it's still bad. There's nothing in the file-icons package that could possibly trigger a crash; it's clear that whatever you're experiencing is unrelated to this package.

Note that in the above screenshot, two of the package's icons are failing to load. This is either because

1. You've installed this package to a non-standard path which isn't ~/.atom/packages/file-icons

Or,

2. Something is screwing with Atom's internals at startup, which has somehow screwed up path resolution.

I can't think of what else it might possibly be.

[kevinlieser]

Okay it do not find file:///Applications/Atom.app/Contents/Resources/app.asar/fonts/devicons.ttf?xqxft6 – but cannot follow the path as I cannot "open" app.asar.

But this problem also appears direct after launching atom and open the dev console directly (which do not crash).

Okay, have to put an issue on atom issue tracker.

[Alhadis]

…`devicons.ttf?xqxft6

Why does this URL end with a query string?

but cannot follow the path as I cannot "open" app.asar.

Just for the record, you can unpack it using asar. It's like Atom's own version of a .tar file.

[kaiyoma]

I just started seeing this after the most recent update to file-icons (2.1.35). I'm running Atom 1.40.1 on Windows 10 and I'm seeing the same issues reported originally: file icons change sporadically when opening/closing certain directory sub-trees, file icons appear for directories, directory icons appear for files, etc.

[Alhadis]

@kaiyoma Okay, that's bad. Is there anything unusual about the filesystem in which the affected files reside? E.g., is it a remote drive (like a network file-share)? Are you using WSL?

Also, could you provide a list of packages you have installed? Run apm list --bare --installed in your terminal and copy+paste the output.

[kaiyoma]

Nothing unusual about the filesystem: it's a local clone of a git repo on my hard drive (NTFS). Not using WSL; I use the bash shell that comes with git for Windows.

The problem seems to affect only really specific files/directories in the tree. There's one file in particular that I can always go to which will trigger this problem.

$ apm list --bare --installed
busy-signal@2.0.1
file-icons@2.1.35
highlight-selected@0.16.0
intentions@1.1.5
language-groovy@0.7.0
language-jenkinsfile@0.1.1
linter@2.3.1
linter-eslint@8.5.5
linter-jsonlint@1.4.0
linter-stylelint@4.4.9
linter-ui-default@1.8.0
minimap@4.29.9
prettier-atom@0.57.2
sort-lines@0.19.0
tablr@1.8.3
trailing-spaces@0.4.0

[kaiyoma]

Here's a small video showing the issue: https://imgur.com/a/8keVLuf

When the video starts, you can see that collection.js has the wrong icon (it has the TypeScript icon). When I open that file, the icon fixes itself, but the icon for case.ts also changes... to the wrong icon! Now it's showing the JavaScript icon, even though it's a TypeScript (.ts) file. After closing both files, I can repro the problem over and over.

[kaiyoma]

Still seeing issues. Any word on this? Found a new example today:

The first styles.less is mis-classified as a directory and doesn't open correctly. The second styles.less is just fine. If I disable the plugin, then both files open as normal.

[Alhadis]

@kaiyoma After clicking the "folder" which fails to open, do you see any error messages being displayed in the dev-console?

[kaiyoma]

@kaiyoma After clicking the "folder" which fails to open, do you see any error messages being displayed in the dev-console?

No, I don't see any warnings or errors. Admittedly, the behavior seems to change slightly every time I open Atom. Now the files are opening, but the file icons randomly change between correct and incorrect.

[kaiyoma]

I just saw this behavior today while trying to open a file from the Find File (Ctrl + P) widget, not from double-clicking the entry in the sidebar. Again, the file was mis-identified as a directory and so the open process wasn't as smooth as it normally is.

I've had to disable this plugin because it's just too buggy. It's too bad, because I really like the icons, but this bug is way too disruptive to my workflow. If this issue gets fixed, I'll start using this plugin again.

[Alhadis]

@kaiyoma Try disabling the package's modeline, hashbang, and .gitattributes strategies. This will stop file-icons from making any filesystem calls, which are most likely the catalyst. If this doesn't fix your issue, then I'd suspect there's interference from another package.

[kaiyoma]

@kaiyoma Try disabling the package's modeline, hashbang, and .gitattributes strategies. This will stop file-icons from making any filesystem calls, which are most likely the catalyst. If this doesn't fix your issue, then I'd suspect there's interference from another package.

Forgive my ignorance, but how do I do that? Happy to help out here.

[Alhadis]

Settings → Packages → Search for file-icons → Scroll down to Match strategies

[kaiyoma]

Settings → Packages → Search for file-icons → Scroll down to Match strategies

Great, thanks. Disabled those settings and will rock this for a while and report back.

[kaiyoma]

Settings → Packages → Search for file-icons → Scroll down to Match strategies

Great, thanks. Disabled those settings and will rock this for a while and report back.

I haven't noticed this issue since changing these settings. 👍

[kaiyoma]

I haven't noticed this issue since changing these settings. 👍

Evidently I spoke just a bit too soon. I'm now seeing this problem again in a new project and I haven't changed any settings. Back to square one. 😢

[kaiyoma]

Here's another example of this issue:

In the upper highlighted area, package.json and README.md are picking up the icon from rollup.config.js for some reason. However, in the next directory down (the lower highlighted area), everything is fine.

[kaiyoma]

Found another one today: https://imgur.com/yGhx8z9

Initially, a directory has the wrong icon. When I click on it, the icon changes to the JSON icon, presumably because both files in the directory are JSON files.

Anything I can do to help out or gather more information? Problems like this are a bit infuriating, especially since there really isn't any other comparable icon package I can switch to.

[nszaaa3]

hey, the problem still exists when the working dir has multiple child dirs.

[Alhadis]

@nszaaa3 Are you running any background tasks, like formatting with Prettier or something? If so, this might be caused by the issue @utkarshgupta137 brought up in #693.

I'll prepare a fix, but I've no way of predicting if it'll solve the issue or not. Fingers crossed. 🤞

[Alhadis]

Folks, I was able to reproduce this issue, finally (I think the fact I recently purchased a modern MacBook might've helped). Managed to pinpoint and fix the catalyst, and you should (hopefully) see this infernal issue fixed with the next release.